James, Thanks for taking your time. Let me address some of your concerns in-between the lines. On 2012-10-08 19:14, James Adcock wrote:
Starting by looking at a desktop browser:
I try downsizing the default window, to see if there are any issues where some aspect of the design is "hardwired" to the assumption of display size and shape.
The HTML is indeed designed to work well on reasonable modern monitors, without consideration for smaller devices.
I find immediately that the cover image isn't scaling nor centering correctly.
Scaling of pictures is not well supported in older browsers, nor possible without resort to non-HTML features such as javascript. Still, using modern browsers, I can scale without issues.
As I downsize the margins appear to be excessive. This will prevent reading the HTML on small display devices which directly understand HTML. For example I open the HTML directly in my tablet, and the margins consume excessive screen real estate.
The problem I try to address here is the landscape portrait aspect ratio of most computers, leading to excessive long lines by default. Tablets and smartphones better approach the traditional book aspect ratio, and thus won't need it.
Horizontal rules I would think were intended to be centered, but are showing up left-aligned.
The separators that split footnotes are not centered. They were not present in the original book, but as footnotes do not translate to a non-paged medium, I placed them as endnotes at the end of the chapter, and needed a separator to make them stand out. Note that asymmetric footnote separators can be seen in old books for footnotes continued on the next page in traditional typography.
Chapter headings are left aligned, where I suspect in the original book and in common usage they should be centered.
That is a matter of taste and convention. I normally use this stylesheet, but have others that allow centering. We've of course all read Jan Tschichold's Asymmetric Typography.
I see gesperrt, which I suspect will be troublesome on other platforms, we will see later. I also see use of margin page numbers, which will typically cause problems, again we will check this later.
Gesperrt is nasty, but very common in old Dutch and German books (This book was originally in antiqua (i.e. normal roman font), but fraktur fonts didn't have italics at all.) A simple stylesheet change can fix it, but then I loose the contrast with italics. Older typography often goes over the top with use of letter-spacing, italics, and small caps.
Next I try opening the EPUB in ADE. EPUB comes close to implementing most of HTML, and ADE is a pretty robust implementation of EPUB (with a few quirks) so this should not be a hard test:
The ePub was made by epubmaker, for which I take no responsibility. I've now also uploaded my own ePub version to this location: http://www.gutenberg.ph/previews/blumentritt/EthnographiePhilippinen.epub, for some further review.
" Druckfehler und Berichtigungen" table doesn't work in EPUB.
The table uses cells spanning multiple columns. If ADE can't handle that, they should fix it.
Gesperrt doesn't come through to epub, but you have italicized the entries anyway, so no great loss.
This seems like an issue with the stylesheet falling back to default rendering.
Epubmaker seems to have successfully killed your page numbers, which arguably is a good thing.
In my own ePub I kill them as well.
Tables don't format correctly, don't scale, and "run off the right edge of the display."
For which it is sometimes hard to find a reasonable solution. Sometimes, original tables span two columns in small print. Compressing that to a small window device will require re-designing the entire table.
Next, let's test how much your code relies on unportable aspects which are being masked by having epubmaker "fix" these problems for you. This is interesting because we want PG books to be "write once read everywhere" which means that your HTML should be portable directly, and should not require epubmaker "fix-ups."
My master is TEI, not HTML, from the TEI I should be able to generate reasonable ePub. (I won't do Kindle directly, as that format is proprietary, and closely linked to the Amazon infrastructure)
We can test portability by directly opening the HTML in Kindle Previewer. This compiles the EPUB and the mobi7 and mobi8 directly, without given epubmaker a chance to try to cover for any mistakes:
Mobi8 (epub, device="Kindle Fire"):
The margins a WAY excessive, consuming most of the screen real estate.
Agreed for ebook readers.
The cover image doesn't work, there is some kind of image format problem.
There is no standard way of dealing with cover images in ePub 2.0; 3.0 addresses this.
TOC has a fixed vs. float formatting problem where "Seite" and page number "1" are trying to occupy the same place and are writing over each other.
Seen the issue, need to fix that by giving the line "Seite" stands on some positive height. Will investigate.
In general the TOC has fixed vs. float formatting problems causing overwrites.
The TOC is formatted as a table using spans; the table implementation seems broken.
"[Inhalt]" keeps showing up "everywhere"
In HTML, which has no standard navigation aids (unlike some ePub readers) those help to give quick access. They are superflous in ePub, and this not present in my ePub version.
Footnote numbers render unattractively and intrusively in body text.
Here I have a usability issue: to be able to follow links to footnotes, they need to be large enough to tap upon, but that looks ugly (I haven't resolved this issue yet.)
No vertical whitespace before or after chapter headings.
OK, now let's go back and take a look at the actual HTML code, and see if we can learn anything:
Hmm, the CSS runs to about 700 lines of code!
Correct, I use a standard stylesheet for all my books, and I still have to code a tool that removes unused CSS code. That problem is surprisingly hard.
Cover size is being "hardwired."
All image sizes are specified in pixels to match the actual images. This works great in the original HTML as it allows the browser to set the formatting before all images are downloaded.
Out of curiosity, what happens if the 700 lines of CSS are removed? I recompile again directly using Kindle Previewer. The appearance doesn't change greatly, for better or for worse, but now at least "sensible" paragraph formatting is working both in mobi8 (epub) and mobi7.
Still, I want to be clear that this book shows fewer formatting errors than most PG books I look at.
I am glad to hear that. Jeroen.