Thread: Kobo Bug thread
View Single Post
Old 11-14-2019, 10:44 AM   #1178
jackie_w
Grand Sorcerer
jackie_w ought to be getting tired of karma fortunes by now.jackie_w ought to be getting tired of karma fortunes by now.jackie_w ought to be getting tired of karma fortunes by now.jackie_w ought to be getting tired of karma fortunes by now.jackie_w ought to be getting tired of karma fortunes by now.jackie_w ought to be getting tired of karma fortunes by now.jackie_w ought to be getting tired of karma fortunes by now.jackie_w ought to be getting tired of karma fortunes by now.jackie_w ought to be getting tired of karma fortunes by now.jackie_w ought to be getting tired of karma fortunes by now.jackie_w ought to be getting tired of karma fortunes by now.
 
Posts: 6,252
Karma: 16544692
Join Date: Sep 2009
Location: UK
Device: ClaraHD, Forma, Libra2, Clara2E, LibraCol, PBTouchHD3
Quote:
Originally Posted by John F View Post
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.

Isn't that the purpose of the epub spec: not needing to know the each implementation of the an epub renderer as to where fonts are stored, how they are named, ...

And in case it isn't clear, I'm not talking about some random mal-formed corner case epub; I'm asking about well formed commercial epubs where the coder knows what they are doing, so they can get expected results on as many platforms as possible.
Unfortunately, there's some wishful thinking in there.

Standard epubs (not just on Kobo) have always required CSS @font-face statement(s) containing the precise path to the font file(s) to be used. Sometimes that path points to a file inside the epub (standard coding for embedded fonts). Sometimes (Kobo and Sony) you can employ tricks to point to a file stored on the device itself - which saves all that messing around with font embedding.

In addition, Kobo (and probably other Adobe RMSDK users) does have a part of the firmware (the Adobe RMSDK part) where there are instructions (for standard epub not kepub) telling the Adobe renderer what to do with the generic font-family values:
- font-family:serif should use Georgia
- font-family:sans-serif should use Avenir
- font-family:monospace should use CourierStd

Unfortunately, CourierStd is not included in the Kobo firmware. Even if it was the code is wrong because the coded CourierStd filenames do not match the strict naming convention Kobo uses. The kobopatch I've mentioned previously corrects the faulty pointers to non-existent CourierStd files allowing the user to set correct pointers to a sideloaded font-family which does exist. But patching is hacking and not everyone wants to do that ...


As for the Kobo automatically deducing which of its available fonts can be used for monospace ...

When the Kobo loads and merges its built-in fonts plus your sideloaded fonts I don't believe it has any idea what each of those fonts is (serif, sans-serif, monospace, small-caps, cursive, ...). We know the internal fontname is important to Kobo but there is too much variation to form reliable conclusions based on fontname only.

If you open a font file in a font editor you can see an enormous amount of metadata. Some of those fields might be useful but you can bet your bottom dollar that font creators have not applied that metadata consistently over the years - much like publishers have no agreed standards about adding metadata to ebooks. Add to that the fact that fonts have been used by major corporations (Microsoft, Apple, IBM, Adobe, ...) who will never agree on standards unless they're the ones controlling the standards.

BTW, I'm no expert on epub standards either, but I have had a lot of practice looking for usable workarounds on various eink devices and Android apps.
jackie_w is offline   Reply With Quote