
On 4/19/2010 11:26 AM, Jim Adcock wrote: [snip]
PS: I already to make preview versions of my HTML on ePub and MOBI -- its just that the HTML->ePub and HTML->MOBI conversion software I have is not identical to Marcello's and thus the formatting ends up different than the "official" version.
If true, this is troubling. Because .epub is just a ZIP file, you should be able to open the archive in your favorite tool (WinZip, WinRar, 7-Zip, PowerArchiver, whatever) or use gzip -x and extract all the files. The HTML file(s) should be identical to whatever the source was. If they differ, the differences had better be harmless (making the source valid XHTML, for example). If they /do/ differ in substantive ways, Marcello should revisit his "publishing" code. It is possible, however, that if an .epub file looks different when rendered than the source HTML perhaps the archive contains a default stylesheet that alters the appearance. BTW, to create a valid .epub file, start by creating an .opf file which describes the publication. One extracted from an existing .epub file should give you a good example of what is necessary. Then create a container.xml file that references the .opf file you created. Put this file in a subdirectory called "meta-inf". Lastly capture the mimetype file from an existing .epub. Now, add "mimetype" to a zip file, *without compression*. Then add the .opf file, the content XHTML file(s), and meta-inf/container.xml. Rename the file to ".epub", and voilĂ , you have a valid .epub file. Of course other files can be added as well (such as font files and stylesheets), but they are just gilding the lily. The actual paths of the various files are irrelevant except for the container.xml file, which *must* be in the meta-inf/ folder (and of course the paths to the files must be correctly recorded in the .opf file). I think it is only polite to add the .opf file to the archive second, and to leave it uncompressed, but that is fairly uncommon. The OCF specification requires that the mimetype file be the first file in the archive (so it can always be found at a specific byte offset), but I know of no .epub reader that actually enforces this requirement.