Bug #3434
closed
EXPath archive:create-map doesn't honour compression level
Category:
EXSLT extensions
Fix Committed on Branch:
9.8
Fixed in Maintenance Release:
Description
The two-argument form of archive:cerate-map doesn't appear to be implemented.
The single-argument form of archive:create-map doesn't seem to honour the compression-level entry-level option, so that I can't turn off Zip compression for the "mimetype" entry for an EPUB 3 zip archive.
Admittedly the documentation on the values for compression and compression-level seems very sparse so I might just be doing it wrongly!
I've enclosed an XSLT stylesheet that attempts to write out two files, one with no compression and one with default compression. When run (with itself as input) it creates "output.zip"; Expected result is that if you examine the zip file directly - e.g., in a terminal, less < output.zip, the contents of "mimetype" should be visible, uncompressed. Or, run unzip -l -v on the file and see that it reports Def:N -10%.
I'm using the Saxon EE that comes with oXygen XML Editor 19, 9.7.0.15; also tried PE with the same result.
Files
- Category set to EXSLT extensions
- Assignee set to John Lumley
- Priority changed from Low to Normal
- Status changed from New to In Progress
Indeed, the 2-arity arch:create()
hasn't been implemented, and per-entry compression level hasn't either. (We mostly focussed on reading in testing.)
We'll implement (and document) per-entry compression for Saxon 9.8, but not 9.7. In this case the only supported compression
values will be '@stored@' and '@deflate@' (corresponding to those in java.util.zip.ZipEntry@) and the @compression-level
property will be meaningless. The documentation will be updated to reflect the implementation.
(Is there ever a day you wear shoes and socks Liam?)
Many thanks for looking at this. I'll find a workaround for the next
few months if necessary; per-entry compression is needed (alas) to make
EPUB 3 archives, and is supported (with archive elements) by xerces in
Cocoon.
On Thu, 2017-09-14 at 13:33 +0200, Saxonica Developer Community wrote:
- Applies to branch 9.8 added
- Applies to branch deleted (
9.7)
Changes committed to 9.8 trunk(?). Leaving in progress until documentation sorted.
- Status changed from In Progress to Resolved
- Fix Committed on Branch 9.8 added
Marking as resolved. The online documentation will be updated with the next 9.8 maintenance release (so in particular, the updates relating to this bug will appear then).
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.8.0.5 added
Bug fix applied in the Saxon 9.8.0.5 maintenance release.
Please register to edit this issue
Also available in: Atom
PDF