creating epub: updating file

[marcostt]

Hi.
First at all, sorry about my english.

I create my epub with sigil. No problem until someone told me that the epubs lost the spanish tildes (accents, á, é...) in some ereaders like Sony Reader. I could not found why, but, anyway, I try to resolve it changing accentes by code. I work in iMac, and:

- Unzip the epub, and it is created a folder with the name of the epub.
- Open the folder, open the folder called OEBPS and then the folder Texts.
- I did open all the text files and changed the á, é... for á é...

But I have now problem, sure a stupid problem: I dont know how to update the epub, how to get create an epub file with theses text files modifieds.

Please, can someone explain me how to get it?

Thanks in advance,
Marcos

[DMSmillie]

Rename the original epub file, just in case you need to go back to it.

Inside the folder you created when you unzipped the epub file, create a new zip file with the filename you want to use for the epub file, but with the file extension .zip.

First, add the "mimetype" file to the zip file.

Then add the rest of the contents of the folder, including the sub-folders, to the zip file.

Finally, change the file extension of the new zip file to .epub.

You should now have a revised version of your epub file, with the changes you made.

[Ankh]

Originally Posted by DMSmillie

First, add the "mimetype" file to the zip file.

Then add the rest of the contents of the folder, including the sub-folders, to the zip file.

That is not precise enough according to the standard. Although some of the reading platforms might read non-standard epub files.

The rules for the "mimetype" file are defined in Open Container Format, and the text of interest (bold text used for emphasis, my intervention):

The first file in the ZIP Container MUST be a file by the ASCII name of ‘mimetype’ which holds the MIME type for the ZIP Container (i.e., “application/epub+zip” as an ASCII string; no padding, white-space or case change). The file MUST be neither compressed nor encrypted and there MUST NOT be an extra field in its ZIP header.

So, using command line zip utility, the proper command to add "mimetype" to the archive, while positioned to the directory/folder containing the file is:
zip -X0 <some other directory>\<name_of_the_target_file>.epub mimetype

Note that archive is created in some other directory, which simplifies the next step, adding the rest of the files to the same archive:
zip -Xur9D <some other directory>\<name_of_the_target_file>.epub *

[Jellby]

Originally Posted by Ankh

Now, parameter 8 is the correct value based on this part of the standard:

Hmm... I was not aware of this requirement. I've been creating my ePUBs with 9 since the beginning, and neither epubcheck nor flightcrew have complained. Maybe they should be updated.

[Ankh]

I really don't know what to say, Jellby.

The discussion is entering the realm what is more important, a purist approach to follow the standard "to the letter", or creation of ePub file that works on real implementations of the said standard. I personally don't understand the technical reason why the standard is enforcing, and so strongly, the value of "8". I am also unaware of the implementation that does not accept value "9".

The question is, should the epubcheck and flightcrew be updated, or should we petition the IDPF to accept the experiences of the actual implementation relaxing the requirement in the process?

[Ankh]

Originally Posted by Ankh

The question is, should the epubcheck and flightcrew be updated, or should we petition the IDPF to accept the experiences of the actual implementation relaxing the requirement in the process?

What a mess... I decided to follow through on contacting IDPF. So before doing that, I went on to verify that command line zip parameter is really matching the value in local header, mentioned in the spec. It is not. The compression method field in the header, in the current zip source, can have values:
0-Store
8-Deflate
12-bzip2

So, the standard is prohibiting using bzip2 compression, or any new compression that might be added to the Zip utility at the later date. Which is sensible, as it enforces the known baseline that can be met today and in the future.

The numbered parameters in zip command line utility provide a trade-off between compression speed and compression efficacy. -0 will force "store" method, anything else will use "deflate". So, even if you use value "9", the local header (one for each compressed file) field, mentioned in the spec, will be assigned a value of 8, satisfying spec requirement. What will create a non-standard file and break this requirement is using parameter "-Z bzip2", which is not suggested by any internet epub creation guide.

I do apologize for the mess that I created. My original message will be modified to remove FUD that I created.

[marcostt]

Thanks you very much; I'll try to do it as you said.

Bye

[Jellby]

Thanks, Ankh. I was suspecting something along those lines, since I found that in the python module, zipfile.ZIP_STORED=0 and zipfile.ZIP_DEFLATED=8