Quote:
Originally Posted by davidfor
Of course, as you are agreeing with JSWolf, you must be agreeing about ePub 2.
|
Low blow there…
Quote:
|
Originally Posted by davidfor
That last sentence seems to say that if the renderer only wants to use one actual font for all five faces, they can. And I don't even read the first paragraph as saying the renderer must use a monospace font, just that it provide something.
|
Technically true. Kobo could, if they so desired, provide only Comic Sans and map it to all five generics if they so chose. I think they’d get rather a lot of complaints, though.
I’ll even go so far as to say that it’s reasonable for a platform to slide on “fantasy” and “cursive” defaults… because those definitions are so vague that they’re so rarely used; a designer has no reasonable expectation about what specifying either of those will look like, and that makes a lot of difference. But monospace? There are plenty of reasons to use that, so much so that browsers have allowed users to define it since before CSS was even imagined. Users and publishers alike have a reasonable expectation that a system capable of handling CSS will have a default monospace font installed.
Bottom line, including true monospace support should be a no-brainer. It’s not like this is a new or uncommon use case, and monospace fonts aren’t exactly rare.
Quote:
|
Originally Posted by davidfor
And back to my comment about ePub 2. The CSS standard that uses is a lot vaguer about this.
|
No, it isn’t. EPUB 2 incorporates the CSS2 spec, which contains
the same conditions I originally cited. See section 15.2.6.
Quote:
Originally Posted by davidfor
How do you think that Kobo broke this? I mean, apart from not actually including a monospace font in the firmware, how is it actually broken?
|
Not including an actual monospace font is sufficient for me to consider the implementation broken.
Quote:
Originally Posted by John F
I'm not an epub coder and ignorant of the epub specs, but the above (bolded) really surprises me. I'm surprised that it isn't part of the epub standard that if an epub specifies a monospace font family, and the font is in one the RMDSK specified font search locations, that it doesn't get used.
|
The problem here lies in determining whether or not a given font family is or is not a monospace font. The rendering engine has to actually map the “monospace” generic to a genuine monospace font for the association to be valid, and the same goes for each of the other four generics (although, as noted above, “fantasy” and “cursive” tend to see a lot less action).
I mean, say your program looks in a specified location and finds something called Frit-Qat. How does it determine what variety of font that is? As a human, it’s relatively easy: look at a sample, see if it’s got serifs, see if it uses proportional spacing, compare it to cursive writing, and see if it’s a decorative oddball design.
But software can’t make those judgment calls. You have to make the assessment and tell it… something you can’t really do with sideloaded fonts, which are the only ones users have “legitimate” access to.