Thanks for taking the trouble once again to look at my product. I know my ePubs are far from perfect, as, since I am unable to submit them to PG, I lack some motivation to improve them. Also, I've only been able to test them on PC based readers, which are in general far more forgiving than the small devices they are meant to go on. I normally use Calibre to read, now have also installed nook for PC and ADE. I have regenerated the file with some fixes you suggest, and re-uploaded to the same location. On 2012-10-10 16:13, James Adcock wrote:
http://www.gutenberg.ph/previews/blumentritt/EthnographiePhilippinen.epub,
OK, well to start with you are hardwiring about an additional 2em margins on each side of the "body", which may not sound like much, but it "throws away" about 10% of my display space, and in turn leaves so few words per line as to make the justification spacing between words look ugly. My devices all allow me to increase margin sizes if I want more margin. They do not allow me to remove margins which you have hardwired in for me. I, like most ebook users, would rather that you left the control of margins, fonts, font sizes, etc, up to me and my device, rather than taking away these decisions from me.
I've now removed the margin completely from the stylesheet. I few (exceptional) books I have use marginal notes, for those I can re-introduce it (after some testing).
"Druckfehler" table doesn't format sensibly.
Doesn't reproduce for me on any of the PC based readers. Probably has to do with the width of the table.
Footnote markings in body text are larger than in the actual footnotes themselves, probably better if they match in size.
Footnotes are in their entirety made slightly smaller, including the numbers. I can set them in the same size, but want to keep the distinction.
Again, we disagree about using K&R style chapter and section headings on books. I would say: K&R style on computer manuals, Book style on Books.
I simple matter of switching stylesheets. I don't what you mean by K&R style (Kernighan and Ritchie maybe, but that is about C programming), anyway, I did so to a stylesheet I call classic (and I think I will make it the default from now on for PG submissions).
Excess spacing between chapter and subchapter headings.
Chapter and subchapter headings appear to be "justified" which clearly doesn't work.
That is not my intention, but I do not see it here.
In Mobi7 (in addition to the previous problems):
Title page formatting problems
Paragraph demarcation becomes even more difficult to discern. I would suggest for texts like this which have extremely long paragraphs go to the "zero indent, 1em space between" style of paragraphs as being much easier to read on ebook readers. And again, paragraph demarcation is also difficult to understand because your margin choices are breaking the justification algorithm [which then switches over temporarily to "ragged right"], which also makes it more difficult to discern paragraph boundaries -- since the eye also tends to catch "ragged right" within "justified" text as being a paragraph boundary.
I always use ragged right. For languages with long words like German, that becomes extremely ragged, so some hyphenation should be introduced (but that is really a task of the rendering device, I can only add hyphenation hints...)
Footnote markers aren't rendering as attractively as they did on epub devices, not sure what you are doing.
Mobi7 doesn't have the margins problem -- since it ignores body margins -- but the word justification routine still breaks down because of so many long German words. Suggest perhaps switch to unjustified ?
Spacing between Chapter and subchapter headings now collapse completely. IE the vertical whitespace associated with chapter and subchapter headers disappeared. Did you implement them using top and bottom margins?
The bracket labels on the vertical curly brackets in tables which you implemented using images in the tables -- those bracket labels aren't positioning correctly with respect to the bracket images. (In general positioning of text with respect to images or vice versa is an ill-defined problem in any flavor of html.)
Again, I do not observe this with the browsers I use to test. Alignment between text and images is not always pixel perfect, but well enough if massaged into a table to be workable on all desktop browsers I've seen. This must be an issue with devices.
But again, this work is much better than most I see published by PG.
Thanks once more.