Kobo Bug thread

[davidfor]

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.

When are you going to stop repeating this and actually answer my question? You are making claims and not backing them up.

How sure are you that Kobo broke this (which they didn't) and that the other users of the RMSDK didn't spend time fixing a mess that Adobe supplied them?

Please Jon, put up or shut up. You frequently make claims like this as fact. You never back them up.

[davidfor]

And for the record:

Exactly how many of you have reported this "major bug" to Kobo? If it is such a problem, I'm sure all of you have reported it and explained why it is important. If enough people report the problem, it will change.

And I have asked the question about monospace support. Basically, "not important", and not something they considered was needed. I also asked about the strange path used in the firmware which the patch @jackie_w fixes. That bit probably is a bug. Or at least it is inconsistent with other font paths.

[JSWolf]

Yes, there is a bug and this is it...

From librmsdk.so.1.0.0:
res:///fonts/CourierStd.otf
res:///fonts/CourierStd-Bold.otf
res:///fonts/CourierStd-Oblique.otf
res:///fonts/CourierStd-BoldOblique.otf

Should be...
res:///fonts/normal/CourierStd.otf
res:///fonts/bold/CourierStd-Bold.otf
res:///fonts/italic/CourierStd-Oblique.otf
res:///fonts/bolditalic/CourierStd-BoldOblique.otf

Because of this, CourierSTD cannot be put in fonts and used when monospace is used.

[davidfor]

Originally Posted by JSWolf

Yes, there is a bug and this is it...

From librmsdk.so.1.0.0:
res:///fonts/CourierStd.otf
res:///fonts/CourierStd-Bold.otf
res:///fonts/CourierStd-Oblique.otf
res:///fonts/CourierStd-BoldOblique.otf

Should be...
res:///fonts/normal/CourierStd.otf
res:///fonts/bold/CourierStd-Bold.otf
res:///fonts/italic/CourierStd-Oblique.otf
res:///fonts/bolditalic/CourierStd-BoldOblique.otf

Because of this, CourierSTD cannot be put in fonts and used when monospace is used.

So the only possible bug is that Kobo has some paths inconsistent with their other font paths. The one that I have commented about several times. So the way Kobo have "botched" the RMSDK is by putting in the wrong path. A path that doesn't actually point to anything that they were planning to supply. Or was mandatory for them to supply.

[Rev. Bob]

Originally Posted by davidfor

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

Where technical specifications are concerned, there is a very distinct difference between the three levels of "must," "should"/"recommended," and "may"/"optional." To boil what follows down to a simple TL;DR line: You're interpreting "should" as "may," and that's completely incorrect.

Originally Posted by davidfor

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.

Not only do I own ebooks which use monospace, but I've made and published ebooks which use it.

The plural of "anecdote" is not "data."

Originally Posted by davidfor

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".

You are absolutely, indisputably, provably incorrect.

First, some definitions.

The EPUB 2.0.1 spec consists of three major sections: OPS (content), OPF (packaging), and OCF (container). We are concerned here with OPS, since that's the part dealing with CSS and XHTML and other matters of content. Since the IDPF website is currently offline, and more recent snapshots at the Wayback Machine don't actually allow browsing of that spec, I'm specifically referencing this snapshot.

OPS 2.0.1 incorporates the CSS2 (most accurately, CSS 2.0) spec by reference; that spec is here.

Finally, when I refer to "CSS/x.y.z," that's shorthand for "the CSS 2.0 specification, section x.y.z."

Citing CSS/15.2.6:

Generic font families are a fallback mechanism, a means of preserving some of the style sheet author's intent in the worst case when none of the specified fonts can be selected. For optimum typographic control, particular named fonts should be used in style sheets.

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.

(Boldface mine.)

OPS/3.3 modifies this by dropping "fantasy" and "cursive" from the list of five. Note the highlighted phrases; monospace is inarguably well "within the limits allowed by the underlying technology" of an e-reader. Note also the word "should" in the final sentence; it has a specifically defined meaning in this context.

See also OPS/1.4.2.ii: "[The Reading System must] recognize all markup described as permitted in this specification and processes it consistently with the corresponding explanations in this specification and in those of XHTML 1.1, CSS 2, and DTBook (in case of any conflict, this specification takes precedence)".

Finally, consider OPS/3.4, which deals with embedded fonts:

Content creators must not assume that any particular font format is supported. Fonts could be included in multiple formats by using a list of files for the src descriptor; the first supported format should be used. At least one file in OpenType format should always be included in the list. It is advisable for a Reading System to support the OpenType font format, but this is not a conformance requirement; a reading system may support no embedded font formats at all. Content creators should use comma-separated lists for font-family properties to specify fallback font choices.

(Boldface and monospace in original. Note that "format" refers to file format, not font family.)

Now, remember how I said there was a significant difference between "should" and "may"?

Both CSS/3.1 and OPS/1.4 specifically state that certain keywords - specifically including "must" and "should" and "may" - are to be interpreted as defined in RFC 2119. You appear to believe that "should" means "this is a good idea, one we recommend following, but it's ultimately optional and this is just a guideline." That is not at all true. RFC 2119 states:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

Or, in layman's terms, you'd better have a damned good reason for not doing it. What such reason exists here?

Review time.

Reading Systems MUST comply with CSS2, except as modified by OPS/3.3, which drops the "fantasy" and "cursive" families but retains "monospace".

Reading Systems MAY completely decline to support embedded fonts.

Per CSS2, Reading Systems SHOULD "express the characteristics of each [generic] family as well as possible within the limits allowed by the underlying technology." That means that "monospace" should be rendered as monospace.

Bottom line? According to the relevant specs, a conscientious author is on firmer ground expecting that a Reading System will support "monospace" than he is if he assumes that it will support embedded fonts.

Therefore, your advice to "embed a monospace font if you want to use monospace" is completely wrongheaded. You are advising ebook designers to rely on an optional feature to patch a hole in a recommended feature.

This. Is. A. Bug. It's that simple.

[jackie_w]

Originally Posted by JSWolf

Yes, there is a bug and this is it... <snip>
Should be...
res:///fonts/normal/CourierStd.otf
res:///fonts/bold/CourierStd-Bold.otf
res:///fonts/italic/CourierStd-Oblique.otf
res:///fonts/bolditalic/CourierStd-BoldOblique.otf

Not quite. If the internal fontname was CourierStd the correct links would be:

res:///fonts/normal/CourierStd
res:///fonts/bold/CourierStd
res:///fonts/italic/CourierStd
res:///fonts/bolditalic/CourierStd

In addition (based on all previous experiments) the Kobo wouldn't like file-endings of -Oblique.otf and -BoldOblique.otf. Those would need to be changed to -Italic.otf and -BoldItalic.otf respectively.

This is only a guess on my part but, the fact that these paths are so wrong suggests that it is a piece of Adobe code which has never been changed at all from the original, rather than one where a developer has changed it erroneously. Maybe Adobe wanted to charge a lot of money for Kobo to have the rights to distribute CourierStd so it was always a non-starter. It's offered for sale here at $99. That's $99 more than I'd want to pay for it .

[JSWolf]

Originally Posted by jackie_w

Not quite. If the internal fontname was CourierStd the correct links would be:

res:///fonts/normal/CourierStd
res:///fonts/bold/CourierStd
res:///fonts/italic/CourierStd
res:///fonts/bolditalic/CourierStd

In addition (based on all previous experiments) the Kobo wouldn't like file-endings of -Oblique.otf and -BoldOblique.otf. Those would need to be changed to -Italic.otf and -BoldItalic.otf respectively.

This is only a guess on my part but, the fact that these paths are so wrong suggests that it is a piece of Adobe code which has never been changed at all from the original, rather than one where a developer has changed it erroneously. Maybe Adobe wanted to charge a lot of money for Kobo to have the rights to distribute CourierStd so it was always a non-starter. It's offered for sale here at $99. That's $99 more than I'd want to pay for it .

Thanks for the correction.

If you are correct about the code being left over from RMSDK, then it would go to proving that monospace is part of RMSDK and that Kobo just didn't do anything with it.

[jackie_w]

Originally Posted by JSWolf

Thanks for the correction.

If you are correct about the code being left over from RMSDK, then it would go to proving that monospace is part of RMSDK and that Kobo just didn't do anything with it.

Well, not really. It doesn't prove that Adobe were willing to include the CourierStd font files for mass distribution at no extra cost. We just don't know.

[Rev. Bob]

Originally Posted by davidfor

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:

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:

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.

[davidfor]

@Rev. Bob: I have read what I need to of you reply and have the following comments:

Firstly, all specs are up to the interpretation of the developers involved. And unless they say that something must be done in a particular way, then what is done will be up to the interpretation of the developer. I do not not read any of these as saying must. "Should" does not mean "must". And no, I am not interpreting "should" as "may". I am interpreting "should" as "should". And that means "It would be a damn good idea if you did this, but, you don't absolutely have to do it".

My comment about epub 2 was because you supplied links to CSS for epub3 and epub2. They were different links. I read both. They were not identical. The text is very different and in no way was it word-for-word the same. If you pointed to the wrong thing, then you should have said that rather than accusing me of not being able to read.

Yes, my comment about how rarely I have seen monospace is anecdotal, as is yours. An no, neither proves that anything other than we have different book. But, do you really believe that books that need monospace in them are actually a significant percentage of all books out there? Kobo have got the stats based on all the books they see. They don't see this is important to them.

For the record, I was surprised when I first realised that there was no monospace font supplied. But, I've never considered it a bug. I see it as a missing feature, and not a particularly important one. I can list a lot of things I'd like to see on the device before this. And, as I always say at this point, if you have a problem, report it to Kobo. If you don't, then there is no reason for them to fix or change something as it is obviously not important to you.

[DNSB]

Originally Posted by Rev. Bob

This. Is. A. Bug. It's that simple.

If you are going to quote specifications, perhaps you should have included this quote (bolding mine):

2.4 Fonts

EPUB 3 does not require that Reading Systems come with any particular set of built-in system fonts. As occurs in Web contexts, users in a particular locale might have installed fonts that omit characters required for other locales, and Reading Systems might utilize intrinsic fonts or font engines that do not utilize operating system installed fonts. As a result, the text content of an EPUB Publication might not natively render as intended on all Reading Systems.

To address this problem, EPUB 3 supports the embedding of fonts to facilitate the rendering of text content, and this practice is advised in order to ensure content is rendered as intended.

Support for embedded fonts also ensures that characters and glyphs unique to an EPUB Publication can be embedded for proper display.

And from the item you posted (bolding again mine);

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.

Reading that section, it would appear that if I have one font available and map all fonts to that one font, I am within the intent of that section.

And just for the heck of it, I ran a search on my epub file collection for the use of a monospaced font, <code> tags, etc.. Then I went through and removed those that embedded a monospace font. The final result is that I have 4 epubs with an embedded monospaced font and 5 epubs that use monospace without including an embedded font for a total of 9 out of 9812 epubs. Andy Weir's The Martian is the only one that bothered me enough to add a monospaced font to the fonts directory on my Kobo ereaders.

[MGlitch]

Originally Posted by Rev. Bob

Therefore, your advice to "embed a monospace font if you want to use monospace" is completely wrongheaded. You are advising ebook designers to rely on an optional feature to patch a hole in a recommended feature.

This. Is. A. Bug. It's that simple.

By this logic the Kobo eink screens not rendering full color is a bug.

I can put a color image into an ebook, in fact many ebooks exist in multitudes of formats which already have color images. Far more so than ebooks which require or even use monospace.

There are color eink screens available in various levels of quality.

There are devices which properly display the image in full color.

But it's not a bug.

Also you can rant on all you like, but your own words prove you wrong, last I checked recommended did not mean required, it did not imply you had to do anything. All it means is the feature is suggested to be included.

And thus far you've shown no evidence that it must be done, while others have shown evidence that it's at most suggested.

You are thus calling the lack of an optional feature a bug when its omission was a choice. While also trying to shoehorn in that content creators shouldn't have to make a choice to embed a font to ensure their content is displayed how they want it to be.

[Rev. Bob]

Originally Posted by davidfor

@Rev. Bob: I have read what I need to of you reply and have the following comments:

I read that far and suspected that line was all I needed to read of your response.

I was right. You keep interpreting “should” much more loosely than the RFC 2119 definition allows. In doing so, despite your protests to the contrary, your interpretation is closer to that document’s “may” than its “should.”

Originally Posted by davidfor

I am interpreting "should" as "should". And that means "It would be a damn good idea if you did this, but, you don't absolutely have to do it".

Simply untrue. Again, the RFC language for “should” says “there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.”

That’s much more stringent than “it’s a damn good idea to implement X.” It is a dire warning to the developer to think really damned hard and consider all of the ramifications before omitting the feature, because getting rid of it is a really serious matter.

Figure it this way. In the legal system, one MUST not commit rape. There’s no circumstance where it’s permissible. By contrast, one SHOULD not kill. There are a couple of situations where that’s allowed, but you’d better think hard before pulling that trigger, because the consequences could be dire. (For “may,” the best I can come up with right now is speeding. If you’re going five miles over the limit, maybe ten, most cops won’t care. In that sense, strict adherence to the posted limit is pretty much “optional.”)

Originally Posted by DNSB

If you are going to quote specifications, perhaps you should have included this quote (bolding mine):

And from the item you posted (bolding again mine);

First cite: You’re really reaching on that “any particular set of built-in system fonts” front. That translates to “don’t count on Helvetica, Arial, Times New Roman, or any other specific font face being present.” If anything, that underscores the importance of the three generics. It certainly does not diminish them, and in no way does it mean anything remotely like “don’t count on the generic families being recognized.”

Second cite: Read the sentence immediately following the parenthetical element you bolded.

Originally Posted by DNSB

Reading that section, it would appear that if I have one font available and map all fonts to that one font, I am within the intent of that section.

Nope. “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.”

And remember, “should” has a very explicit meaning in this context.

Originally Posted by MGlitch

By this logic the Kobo eink screens not rendering full color is a bug.

Utter nonsense.

The more correct example would be the Kobo app forcing images to grayscale despite running on a device with a color screen. There’s no technical justification for the behavior, and it improperly violates the author’s intent.

Originally Posted by MGlitch

Also you can rant on all you like, but your own words prove you wrong, last I checked recommended did not mean required, it did not imply you had to do anything. All it means is the feature is suggested to be included.

The governing definition, spelled out in the RFC, says otherwise.

You’re applying a vernacular definition to what, in this context, is a technical term. You might as well say that C++ programmers can end lines of code with emdashes instead of semicolons, on the grounds that the rules of English grammar permit emdashes to be used that way.

Different context, different rules.

Originally Posted by MGlitch

And thus far you've shown no evidence that it must be done, while others have shown evidence that it's at most suggested.

You are thus calling the lack of an optional feature a bug when its omission was a choice. While also trying to shoehorn in that content creators shouldn't have to make a choice to embed a font to ensure their content is displayed how they want it to be.

Go read the RFC. Compare item three (“should”) with item five (“may”). Guess where you’ll find “optional” defined?

5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)

”Should” explicitly does not mean “optional.” The definitions are quite clear.

[MGlitch]

Originally Posted by Rev. Bob

Utter nonsense.

Yes, what you're espousing is utter nonsense.
[/QUote]
The more correct example would be the Kobo app forcing images to grayscale despite running on a device with a color screen. There’s no technical justification for the behavior, and it improperly violates the author’s intent.
[/quote]

And it would still be a deficiency especially if done intentionally. Not a bug. You really might want to spend some time learning what constitutes a bug versus a deficiency.

Go read the RFC. Compare item three (“should”) with item five (“may”). Guess where you’ll find “optional” defined?

”Should” explicitly does not mean “optional.” The definitions are quite clear.

And yet it was your words I was quoting with "optional", not the technical specs. It's adorable how much you want to quote technical specs and yet ignore them as well.

1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the
definition is an absolute requirement of the specification.

2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the
definition is an absolute prohibition of the specification.

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.

5. MAY This word, or the adjective "OPTIONAL", mean that an item is
truly optional. One vendor may choose to include the item because a
particular marketplace requires it or because the vendor feels that
it enhances the product while another vendor may omit the same item.
An implementation which does not include a particular option MUST be
prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality. In the
same vein an implementation which does include a particular option
MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the
option provides.)

Neither "may" nor "should" is defined as "must" or "required", both are specifically stated to not be those, which the mere inclusion of terms like "must" would tell anyone with a modicum of common sense. You can argue levels of "suggested" but it is still never going to reach "required" unless you want to travel to an alternate universe with different rules, or rewrite the rules to your liking. However as it stands your guidelines are not supporting your claim.

The rules of English can be bent quite far, but even these guidelines stay well within them. It is you who are trying to impose an entirely different meaning upon the terms, even such as they are defined here, to try and defend your incorrect stance.

[Rev. Bob]

Originally Posted by MGlitch

And it would still be a deficiency especially if done intentionally. Not a bug. You really might want to spend some time learning what constitutes a bug versus a deficiency.

Riiight.

Well, you’ve just proven that I can ignore you and lose nothing of value. You ought to put those goalposts down; dragging them around like that can’t be good for your back.