Thread: Kobo Bug thread
View Single Post
Old 11-15-2019, 07:59 AM   #1194
Rev. Bob
Wizard
Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.
 
Rev. Bob's Avatar
 
Posts: 1,760
Karma: 9918418
Join Date: Feb 2013
Location: Here on the perimeter, there are no stars
Device: Kobo H2O, iPad mini 3, Kindle Touch
Quote:
Originally Posted by davidfor View Post
And back to my comment about ePub 2. The CSS standard that uses is a lot vaguer about this.
I just realized that I did not completely address this assertion.

I originally cited the CSS3 Fonts specification, section 3.1.1:

Quote:
All five generic font families must always result in at least one matched font face, for all CSS implementations. However, the generics may be composite faces (with different typefaces based on such things as the Unicode range of the character, the language of the containing element, user preferences and system settings, among others). They are also not guaranteed to always be different from each other.
That’s the current spec for general use, primarily on the Web. Remember RFC 2119 and note “must” be matched, “may” be composite, and “not guaranteed to always be” (translation: not the mandatory “must be,” but considerably stronger than the optional “may be,” and therefore equivalent to or stronger than “should be”) different.

However, EPUB 3.0 (there’s no such thing as an “ePub” spec) incorporates the older CSS 2.1, which states in section 15.3.1:

Quote:
All five generic font families are defined to exist in all CSS implementations (they need not necessarily map to five distinct actual fonts). User agents should provide reasonable default choices for the generic font families, which express the characteristics of each family as well as possible within the limits allowed by the underlying technology.
Again, note the use of “should” in the context of RFC 2119. That’s not meaningfully different from the CSS Fonts 3 language, although it is expressed differently.

Finally, EPUB 2.0.1 incorporates the even older CSS 2.0. The relevant language there is in section 15.2.6, and it is word-for-word identical to the CSS 2.1 paragraph above.

The current language may appear stronger to the layman, but on the matter under discussion, there is little technical difference between them to a programmer. Basically, the current spec takes into account that Unicode is frakkin’ HUGE and permits a system to have one big font to define the rare glyphs as an ultimate fallback.

In other words, if you use a Russian word (on an English system), a symbol, or an emoji but you don’t provide a font, you’re likely to get whatever the system can come up with… regardless of whether you specified serif, sans, or mono, and you don’t get to complain. Be glad the system had it at all.

Common glyphs, however, are a different matter. An English-language designer has every reason to expect that basic Latin characters can be styled as simple monospace and will be rendered as monospace. After all, as noted above, EPUB 2.0.1 dictates that embedded font support is only optional, while monospace support is recommended.
Rev. Bob is offline   Reply With Quote