Support for Microsoft's reference XPS files containing [x].pieces?

Dec 17, 2014 at 9:00 PM
Hi,

First, thanks for this very useful library.

Sorry, now the bad news. I’ve been trying to read Microsoft’s sample test XPS files as well as my own created by printing to file, and ran in to a whole series of assertions and failures. (I'm developing in Windows, and building for Mac and Linux too.)

For example, "Zip64I_60FixedPage_out.xps" from http://msdn.microsoft.com/en-us/library/windows/hardware/gg463422.aspx fails in opcContainerOpen() when I try to read it.

Here's what I've found so far...I see some code related to [x].piece files in the libopc source, but it does not appear to be complete or working yet. For example, I haven’t found any code which keeps data for more than one “[x].piece” per “part”, and the code asserts and fails on the second piece.

And, another unrelated problem...If I sneak past all of those errors, then the section of code in zip.c’s opcZipLoaderSkip() function below the, "// streaming mode" comment fails. That code is invoked when bit 3 of the general purpose bit flag is set (indicating that the compressed size, uncompressed size, and CRC are not specified in the “local file header”, but instead deferred to the “data descriptor” which follows the compressed data.) Hopefully this is just an isolated problem in this one method.

Question…

Any ideas on if/when XPS files containing [x].pieces, and/or ones containing files with flag bit 3 set may be supported? Or suggestions if I missed something?

Thanks in advance!
Coordinator
Dec 18, 2014 at 9:32 AM
Hi,

The initial project plan for libopc had 64-bit support and [x].pieces support in it. It was cut out because of funding issues. The good news though is that libopc “by design” is ready to support [x].pieces. E.g. it already reads the ZIP files as a “stream” opposed to other ZIP libraries who rely on the trailing index (like e.g. minizip).
We use libopc internally for reading and writing Microsoft Office files which currently do not have issues with 64-bit and probably will never ever have issues with [x].pieces. So to answer your question we currently have no plans to fund 64-bit support and [x].pieces ourselves.

Kind regards,

Florian
Marked as answer by AR7 on 12/18/2014 at 7:00 AM
Dec 18, 2014 at 2:00 PM
Hi Florian,

Thanks for the prompt reply! I do understand your constraints.

It does appear that you may have already given thought to these two ideas...

If you get a little time, I would appreciate any suggestions you may have about the best way to extend libopc to smoothly support .pieces, and what areas would need attention to add 64-bit. For example, I see things like last_segment_id and segment_count which might be the beginnings of .piece support. The first step seems to be accumulating data about the location of each .piece as it is encountered, understanding that they will be interleaved throughout the container, and probably won't even be in order if someone has edited and resaved the XPS file. I'm not sure, but t looks like the intent of the design may have been to hide the complexity of .pieces at the lowest level and allow callers to work directly with whole parts.

Best regards
AR