Epubcheck & Sigil comptibility.

[GoogleCodeExporter]

using Sigil V0.4.2 (windows build) on win xp sp3
and   Epubcheck-3.0b2

What steps will reproduce the problem?
1. build epub using epubcheck:
    java -jar epubcheck-3.0b2.jar travail -mode exp -save -v 2.0
   produces file travail.epub, without error.
2. open epub with Sigil
   gives error:
---------------------------
Sigil
---------------------------
Sigil was unable to load your file.
---------------------------
C:\b\s\Sigil-0.4.2-Code\src\Sigil\Importers\ImportOEBPS.cpp(112): Throw in 
function void __thiscall ImportOEBPS::ExtractContainer(void)
Dynamic exception type: class boost::exception_detail::clone_impl<struct 
CZipExceptionWrapper>
std::exception::what: Unknown exception
[struct zip_iCause *] = 201
[struct zip_info *] = Damaged or not a zip file.

3. Same file opens ok with any unzipper, ADE, Calibre, Reader Library, etc.

4. "manually" created Epub with same files, ok with Sigil and Epubcheck3 ...

Seems to be a compatibility problem with zip libraries ???

Regards,
Joel Schvartz

Original issue reported on code.google.com by schvar...@gmail.com on 19 Oct 2011 at 2:35

[GoogleCodeExporter]

a bit more information:

- Epubcheck created epub give CRC error on 'mimetype'(but opens ok ?):
   testing: mimetype                 bad CRC 2cab616f  (should be 00000000)

- included two brands of epub:
  > travail-zip.epub : 'standard' zip construction using zip.exe (Mark Adler's & Co ..)
  > travail.epc3.epub: using Epubcheck3 option to create epub zipped file.
 (both from same set of files, of course, abd both passing epubceck 3.0 & 1.2 tests)

- see screnshots for differences in zip information

Regards,
Joel Schvartz

Original comment by schvar...@gmail.com on 20 Oct 2011 at 1:33

Attachments:

• travail-epc3.epub
• travail-zip.epub
• travail-epc3.jpg
• travail-zip.jpg

[GoogleCodeExporter]

Hi Joel,
thanks for finding and reporting this.

My inclination is to disable the save functionality from EPUBCheck, at least 
for now. This was added just "for fun" -- EPUBCheck is intended to be a 
read-only tool, and we need to focus our resources on the validation aspects. 
This might be a simple bug to fix, but even so, moving forward EPUBCheck needs 
to remain read-only.

Original comment by markus.g...@gmail.com on 21 Oct 2011 at 11:24

• Changed state: Accepted

[GoogleCodeExporter]

I found this a great option, if you want to "indutrialize" the build of Epub ...
A standard tool to check and build the release could be very handy.
In case of error, the compressed file could be not created ...

EpubCheck would remain 'read-only' on the source files (uncompressed), of 
course.
Which is all that matters, really.

Regards,
Joel

Original comment by schvar...@gmail.com on 21 Oct 2011 at 2:26

[GoogleCodeExporter]

The problem could be that the stored method is used to archive the mimetype 
file (first entry of the zip file), while the other files are archived using 
the deflated method.

Original comment by biord...@gmail.com on 23 Oct 2011 at 5:58

[GoogleCodeExporter]

No, this is normal (well, at least, the same with other 'good' Epubs ...)

What is different, is the mention of filesystem OS = 'FAT', when others say 
NTFS, or UNIX ?

I had the same resulting file on a Solaris 9 platform.

Original comment by schvar...@gmail.com on 28 Oct 2011 at 2:44

[GoogleCodeExporter]

I am still not convinced that this feature is a good idea. Having said that, in 
r288 I committed a change to this code that uses the Apache commons-compress 
library instead of java.util.zip in order to get control of filename encoding 
(this is not supported in JREs lower than 7). 

I tried opening the output archives in Sigil, and it seems to work for me (on 
OSX). More testing needed, of course.

Original comment by markus.g...@gmail.com on 31 Oct 2011 at 1:48

• Changed state: Started

[GoogleCodeExporter]

Markus,
This version is ok for me too.
Thanks.

Joel

Original comment by schvar...@gmail.com on 13 Dec 2011 at 9:12

[GoogleCodeExporter]

Original comment by markus.g...@gmail.com on 15 Jan 2012 at 4:31

• Changed state: Fixed