Kobo Bug thread

[Sam Sahara]

Originally Posted by meeera

... Is it your assertion that a large proportion of Kobo owners are reading non-PDF coding/technical manuals ...

You see ghosts.

[Rev. Bob]

Originally Posted by MGlitch

https://www.mobileread.com/forums/sh...4&postcount=11

This would seem to indicate otherwise

In that message, DNSB discusses the rendering of the HTML <code> element as an answer to a CSS question, along with some gobbledegook about Unicode characters. Those three subjects have nothing to do with each other; DNSB’s reasoning is faulty at best.

Knowing this stuff is literally my job. I get paid for it.

[JSWolf]

Here's a question I hope someone can answer. RMSDK comes with monospace. Why did Kobo break it?

[davidfor]

Originally Posted by Rev. Bob

Mark your calendars, folks…

I have to agree with JSWolf on this one. David, you’re simply wrong.

Of course, as you are agreeing with JSWolf, you must be agreeing about ePub 2.

The CSS Fonts specification defines five generic “fallback” fonts, and every compliant rendering engine is expected to support them. These are serif, sans-serif, cursive, monospace, and fantasy. This is precisely why a well-crafted CSS font declaration will always end with one of those five values; it translates to, “if you can’t find anything else I’ve listed, use the default for this type of text.” Quoting from the spec, section 3.1.1:



“Must.” As in, not “may” or “should.” It isn’t optional. Any user agent which does not do this does not comply with the specification and is therefore in error.

Any particular reason you didn't include the last sentence of that paragraph? To quote it all (with my highlighting):

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 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. And the very next paragraph is:

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.

A "should", not "must". And that last sentence really just lets them do whatever they want.

And back to my comment about ePub 2. The CSS standard that uses is a lot vaguer about this.

[davidfor]

Originally Posted by JSWolf

Here's a question I hope someone can answer. RMSDK comes with monospace. Why did Kobo break it?

I need you to define two things:

What does "RMSDK comes with monospace" mean? Does it mean "Includes a monospace font". Or "renders things marked as monospace"? Or something else.

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?

When you answer, please be specific and details. Or point to actual examples of the problem (beyond no monospace font being supplied, as we all know that).

[John F]

Originally Posted by jackie_w

Short answer - there will always be some kind of modification needed. The mere presence of a sideloaded font is not enough. You also have to tell the epub/kepub exactly where/how to find it.

Patching firmware isn't compulsory but if you don't, simple edits to each epub will be necessary instead - either manually or via calibre.

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.

[Rev. Bob]

Originally Posted by davidfor

Of course, as you are agreeing with JSWolf, you must be agreeing about ePub 2.

Low blow there…

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.

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.

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.

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.

[jackie_w]

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.

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.

[MGlitch]

Not including an actual monospace font is sufficient for me to consider the implementation broken.

As I said, deficient but not a bug. The render is behaving as Kobo lets it.

[John F]

jackie_w, thank you for the explanation and bearing with me.

[Rev. Bob]

Originally Posted by MGlitch

As I said, deficient but not a bug. The render is behaving as Kobo lets it.

By that logic, there’s no such thing as a bug. In every case, the software is behaving as the programmer lets it.

[JSWolf]

Originally Posted by MGlitch

As I said, deficient but not a bug. The render is behaving as Kobo lets it.

That's because Kobo botched it. monospace should work in RMDSK on Kobo Readers. It's a part of ADE which is what RMSDK is. So yes, it is a bug that monospace does not render a monospace font when it should.

[MGlitch]

Originally Posted by Rev. Bob

By that logic, there’s no such thing as a bug. In every case, the software is behaving as the programmer lets it.

Not even remotely true, a bug is when software does something the programmers don't want, such as crashing, not opening something, or as was introduced in 4.18 not properly updating the time remaining in reading progress.

A deficiency is when the program does not do something that some may reasonably expect it to do, such as displaying monospace fonts in this case.

Those books that use them are still readable, though slightly harder, save perhaps for specific languages. I wouldn't be able to comment on how a vertical language would be affected here. Or if it were unable to change fonts, we the user may find it deficient given this is a feature we have come to expect from virtually ever ereader.

I wouldn't have thought the difference need be explained to someone in a technical field where semantics are important because <blah> is not the same as {blah} nor [ blah]

[davidfor]

Originally Posted by Rev. Bob

Low blow there…

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.

And all that is my point. The standards don't actually state that there absolutely must be a monospace font available and used. It just says the text marked as such has to be rendered using something. If the app doesn't include one, or the base OS doesn't include one, then

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.

I don't quite agree. The only books I have in my library that mention monospace are test books. Books someone has created purely to test how monospace works on these devices. If Kobo are looking at stats like that, which is zero purchased books out of 600 and 0 books out of several thousand from other sources, it isn't surprising they think supporting monospace isn't very important.

No, it isn’t. EPUB 2 incorporates the CSS2 spec, which contains the same conditions I originally cited. See section 15.2.6.

That text is quite different to what you pointed to before. And it is a lot less restrictive. The first one is pretty much "You really, really should do this". The one for ePub 2 is more a "it is a good idea to do this".

[MGlitch]

Originally Posted by JSWolf

That's because Kobo botched it. monospace should work in RMDSK on Kobo Readers. It's a part of ADE which is what RMSDK is. So yes, it is a bug that monospace does not render a monospace font when it should.

You can repeat this as often as you care to Jon it doesn't make it true, I'd like you to answer David's questions if you really want to be taken seriously rather than just a mouthpiece on the virtues of RMDSK and ADE.

Just so you don't need to scroll back to the question:

I need you to define two things:

What does "RMSDK comes with monospace" mean? Does it mean "Includes a monospace font". Or "renders things marked as monospace"? Or something else.

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?

When you answer, please be specific and details. Or point to actual examples of the problem (beyond no monospace font being supplied, as we all know that).