On Mon, February 6, 2012 2:47 pm, don kretz wrote:
I would assume PG must be doing something like this now for html files for ereaders. If you know an html file is going to an ereader format, and you know the default css has, say, irrational margins, you adjust the css. It's what css is for.
The last I had heard explicitly was that was that inline styles were forbidden, and external CSS stylesheets were likewise forbidden. Sometimes I have seen really ugly internal stylesheets created by the Tidy function that moves inline styles to internal stylesheets. I haven't examined Mr. Perathoner's epubmaker program, so I don't know if any of these internal stylesheets are rewritten during the conversion process, but based on the specifics of Mr. Adcock's complaints I suspect that they are not.
Lee>I haven't examined Mr. Perathoner's epubmaker program, so I don't know if any of these internal stylesheets are rewritten during the conversion process, but based on the specifics of Mr. Adcock's complaints I suspect that they are not. Marcello (in his epubmaker software targeting epub) moves the internal CSS styles to external style sheets, and adds an additional pgepub.css style sheet at the end. The effect of cascading style sheets is that the last style sheet "wins" over previous specifications, so the pgepub.css style sheet represents an overriding "tweak" of the CSS which the original submitter wrote. One can see this by using any zip software to unpack the contents of a PG epub file and look for files whose names ends in .css since epub is just a standard zip file. Epubmaker does a bunch more stuff which one can see by examining the .htm files. (Unpacking and repacking epub files is pretty standard stuff for people authoring epub files.) Also Marcello adds the "Blue PDA" cover placeholder, and auto-generates a ncx navi file from h1, h2, h3 tags. He also puts page breaks in before h2 tags, even if you have placed page breaks elsewhere, and he divides the input HTML into more bite-sized chunks to match the epub standards requirements, and to make epub devices happy, which can be slow to open epub documents if you try to code epub documents internally just using one huge HTML file. For Kindle Marcello I believe turns a bunch of the external style sheet information back into inline style tags in the generated HTML code in an attempt to overcome limitations in the understanding of CSS style sheets by the original Kindlegen Version 1 software. I think the new Kindlegen Version 2 software does a much better job of handling CSS when generating KF8 code. I'm not sure what Kindlegen Version 2 does when generating *mobi7* code, and whether it is now smarter when it is handling CSS style sheets. One can examine the contents of public domain unencrypted .mobi files such as those generated using epubmaker+kindlegen using a free program called mobi_unpack.py, which turns the content of the .mobi file back into something which looks like a .epub file. This works especially well if the version of Kindlegen called by epubmaker is Kindlegen Version 2. Sigil is also a convenient "workbench" for examining the contents of an .epub file, or an ".epub" file created by mobi_unpack.py from a .mobi file.
On 2/6/2012 4:47 PM, Jim Adcock wrote:
Marcello (in his epubmaker software targeting epub) moves the internal CSS styles to external style sheets, and adds an additional pgepub.css style sheet at the end. The effect of cascading style sheets is that the last style sheet "wins" over previous specifications, so the pgepub.css style sheet represents an overriding "tweak" of the CSS which the original submitter wrote.
This may be true, although in at least one case I saw a slight anomaly between "0.css" and the internal style sheet specified in the .html file. In the case of "Pride and Prejudice" however, it does not apply at all. Instead, the .epub file contains 3 .css files: rst.css, rst-epub.css, and pgepub.css. Strangely, the contents of none of these three files seems to bear any relationship to the styles stored in the HTML file. This leaves me very confused, as it almost looks like the .epub file was generated from an .rst file, but there is no .rst file in the /files/1342 folder. Clearly, Mr. Perathoner wouldn't surface anything via gutenberg.org without convincing the WWers to start using them, so I have no idea where this could have come from.
participants (2)
-
Jim Adcock -
Lee Passey