On dinsdag 8 september 2020 19:31:41 CEST Liam R. E. Quin wrote:
> On Tue, 2020-09-08 at 17:07 +0200, Jos van den Oever wrote:
> > Thank you for making the improvements. This is much cleaner imho than
> > bash +
> > zip + xsltproc. :-)
>
> A minor addition - i've sometimes started with a base zip
On Tue, 2020-09-08 at 17:07 +0200, Jos van den Oever wrote:
> Thank you for making the improvements. This is much cleaner imho than
> bash +
> zip + xsltproc. :-)
A minor addition - i've sometimes started with a base zip file with the
uncompressed "mimetype" entry in it, and just added the rest
Thank you for making the improvements. This is much cleaner imho than bash +
zip + xsltproc. :-)
On dinsdag 8 september 2020 16:59:14 CEST Christian Grün wrote:
> > Creating a new file epub or odf file works correctly now but
> > archive:update() does not retain the 'stored' property for the
> Creating a new file epub or odf file works correctly now but archive:update()
> does not retain the 'stored' property for the manifest file. (It does retain
> the order of the entries).
The stored property will now be retained if an archive is updated.
Up to now, archive:update removed
On dinsdag 8 september 2020 14:40:34 CEST Christian Grün wrote:
> I’ve updated the code; if the compression level is set to 0, entries
> will be STORED [1]. Feel free to check out the latest snapshot [2].
Creating a new file epub or odf file works correctly now but archive:update()
does not
On dinsdag 8 september 2020 14:27:55 CEST Christian Grün wrote:
> Hi Jos,
>
> > There are 5 bytes between 'mimetype' and 'applicatino/epub+zip'. These are
> > deflate information. If the entry is 'stored' there are no bytes between
> > the entry name […]
>
> Great, so we are talking about the
I’ve updated the code; if the compression level is set to 0, entries
will be STORED [1]. Feel free to check out the latest snapshot [2].
[1]
https://github.com/BaseXdb/basex/commit/67ad584a85e0848432e19b4f587fbabfc2fc38e5
[2] https://files.basex.org/releases/latest/
On Tue, Sep 8, 2020 at
Hi Jos,
> There are 5 bytes between 'mimetype' and 'applicatino/epub+zip'. These are
> deflate information. If the entry is 'stored' there are no bytes between the
> entry name […]
Great, so we are talking about the same thing.
> I think the simplest solution is to save compression-level=0 as
To be complete, here is an example to create a file that is recognized as
epub:
$ echo -n application/epub+zip > mimetype
$ zip -D -X -0 test.epub mimetype
$ file -i test.epub
test.epub: application/epub+zip; charset=binary
$ hexdump -C test.epub | head -4
50 4b 03 04 0a 00 00 00 00
On dinsdag 8 september 2020 13:06:19 CEST Christian Grün wrote:
> > Here is an example that creates a new archive that uses
> > compression-level="0" and algorithm="stored" and still compresses that
> > entry.
> >
> > Note that the archive level option 'algorithm' is unfortumate because
> > often
> Here is an example that creates a new archive that uses compression-level="0"
> and algorithm="stored" and still compresses that entry.
>
> Note that the archive level option 'algorithm' is unfortumate because often it
> is only single entries such as 'mimetype' or images that should not be
>
On dinsdag 8 september 2020 11:57:16 CEST Christian Grün wrote:
> > This example demonstrates that compression-level="0" does do what
>
> > the api promises:
> I can have a closer look into that. Could you possibly provide me with
> a little self-contained example that I can run out of the box?
> This example demonstrates that compression-level="0" does do what
> the api promises:
I can have a closer look into that. Could you possibly provide me with
a little self-contained example that I can run out of the box?
On dinsdag 8 september 2020 11:05:45 CEST Jos van den Oever wrote:
> On dinsdag 8 september 2020 10:59:37 CEST Christian Grün wrote:
> > > Oh, a shame that the cross-implementation module is not maintained.
> >
> > The Archive Module was supposed to become the new EXPath standard.
> >
On dinsdag 8 september 2020 10:59:37 CEST Christian Grün wrote:
> > Oh, a shame that the cross-implementation module is not maintained.
>
> The Archive Module was supposed to become the new EXPath standard.
> Unfortunately, different versions of that module were specified one
> after another such
> Oh, a shame that the cross-implementation module is not maintained.
The Archive Module was supposed to become the new EXPath standard.
Unfortunately, different versions of that module were specified one
after another such that the spec that’s currently publicly available
doesn’t reflect our
On dinsdag 8 september 2020 09:57:50 CEST Christian Grün wrote:
> Hi Jos,
>
> While the ZIP Module is still part of our distribution, it’s not
> actively maintained anymore, and we generally recommend our users to
> switch to the Archive Module [1]. Providing custom compression levels
> for each
Hi Jos,
While the ZIP Module is still part of our distribution, it’s not
actively maintained anymore, and we generally recommend our users to
switch to the Archive Module [1]. Providing custom compression levels
for each archive entry is one of the features that is provided by this
newer module.
Hello all,
As you might know, epub files and ODF files are zip files with specific
contents. BaseX supports the expath zip module and could in theory be used for
creating these files if it were not for a missing simple feature.
There is one rule for epub and ODF files that cannot be followed
19 matches
Mail list logo
