Quote:
Originally Posted by Rev. Bob
I am staunchly opposed to any set of standards designed around any one company's platform.
|
The programs I've seen for iOS have these options and some have more. So if we go with that set of options as the base minimum, then we'll be good to go.
Quote:
Taking these one at a time:
- "No margins." On anything? Bad idea. If nothing else, the existing HTML specs define certain default margins; devices should adhere to those rather than defining a new set of defaults that results in contradictions. We'd have the browser wars all over again.
|
No margins is left/right of 0. This means that the software can set the margins. If you have the main margins set to something, you cannot unset and go back. You can only add to it. So 0 means you can have the margins you want using the software's margin settings.
Quote:
|
- "No excessive space." Useless, since "excessive" is a subjective definition.
|
No excessive space is not always subjective. I've seen plenty of eBooks with a wasted space of 14% or similar for the chapter header. That is a waste of space.
Quote:
|
- "No line-height." Setting line-height to zero instantly makes all text unreadable, if strictly implemented. Omitting the parameter for standard-size text is something I can get on board with, but particularly with Kobo, not setting line-height when changing font size is a recipe for disaster. (Ever seen headers that overlap when the text wraps to a second line? That's why that happens. Setting line-height to "normal" when resizing text fixes that.)
|
No line-height is not specifying a line-height and letting the software defaults (along with the font) to handle that. If the program has an option to set the line-height, then the user can increase that if wanted.
Quote:
|
- "No embedded fonts except as needed." Please define "need." It's one thing to define it functionally ("I need to display some emoji characters."), but some people will define it cosmetically ("I need to use this font to convey this style.").
|
No embedded fonts The problem with most embedded fonts is that they don't display well on an eInk screen. They are too light. An example of a very poorly made eBook is
The Martian A very good book but poorly made because of the embedded fonts. The fonts used are free serif, free sans-serif, and free monospace. All of those fonts are terrible on eInk because they are way too light. On a Carta screen, they looked very thin and light. I had to remove them because they did not work. That is an example of not needed.
Quote:
|
- "No paragraph spaces." Back to the browser wars, I see.
|
No paragraph spaces I've seen some programs that have the ability to set the spacing between paragraphs. Not all programs do. But, given that there is no standard for eBooks, might as well go with no paragraph spaces.
Quote:
|
- "Indents of 1.2-1.5em." A range is not a number, so here you're getting into "best practices." I agree that paragraph indents should be around that mark - I use 1.5em, myself - but I would strongly resist making that a default value in the reader.
|
Indents of 1.2em-1.5em is a good idea. I've seen indents as bad as 5% and as bad as 0. When you get paragraph spaces and no indent, it looks like section breaks. That makes it harder to read comfortably.