Kobo Bug thread

[davidfor]

Originally Posted by JSWolf

It is a bug because monospace and the rendering of a monospace font is part of RMSDK. Kobo botched it and hasn't bothered to fix it.

If you include a monospace font in the book and correctly identify it, then you will see monospaced text where ever it is used. And I believe it will render correctly. As Kobo does not include a monospace font in the firmware, any other attempt to use a monospace font will result in using the currently defined font. And that will render correctly.

So, exactly how has Kobo botched rendering of monospace fonts with the RMSDK?

[JSWolf]

Originally Posted by davidfor

If you include a monospace font in the book and correctly identify it, then you will see monospaced text where ever it is used. And I believe it will render correctly. As Kobo does not include a monospace font in the firmware, any other attempt to use a monospace font will result in using the currently defined font. And that will render correctly.

So, exactly how has Kobo botched rendering of monospace fonts with the RMSDK?

If you use font-family: monospace with ADE and every other version of RMSDK, you will get a monospace font. But Kobo is the only one using RMSDK where that doesn't work. So yes, it is a bug on Kobo's part.

[davidfor]

Originally Posted by JSWolf

If you use font-family: monospace with ADE and every other version of RMSDK, you will get a monospace font. But Kobo is the only one using RMSDK where that doesn't work. So yes, it is a bug on Kobo's part.

Wrong. If you use "font-family: monospace" and supply an appropriate font, it will work. As it works, it is NOT a bug.

And for the record, this is like saying Windows has a bug because I specified to use "Some Stupid Font" in a book but did not supply the font so that the application could read the font from.

[PenguinCEO]

Originally Posted by davidfor

this is like saying Windows has a bug because I specified to use "Some Stupid Font" in a book but did not supply the font so that the application could read the font from.

So it's all normal, regular and clear.
The inability of the kobo KA1 to rendering monospaced text out of the box is not a bug: it's a feature.
Well, why Kobo doesn't point out in his web site and on every device box "Beware: This device doesn't supply monospaced type font. It doesn't render monospaced text if fonts are not supplied by the book publisher."
Just for fairness.

Originally Posted by davidfor

... I specified to use "Some Stupid Font" ...

Why are you losing your temper?

[MGlitch]

Originally Posted by PenguinCEO

So it's all normal, regular and clear.
The inability of the kobo KA1 to rendering monospaced text out of the box is not a bug: it's a feature.
Well, why Kobo doesn't point out in his web site and on every device box "Beware: This device doesn't supply monospaced type font. It doesn't render monospaced text if fonts are not supplied by the book publisher."
Just for fairness.

Probably because they’ve allowed adding your own fonts for years and years, possibly going back to the first models but certainly a long enough time that it’s a standard feature.

You want the font, supply it. It’ll render properly. Thus it’s not a bug.

You can pester them for the addition of a monospace font, though I’d suggest being less brusque and dismissive to whoever you talk to via their CS lest your request go in the “special request bin” that gets emptied by maintenance every night.

[PenguinCEO]

Originally Posted by MGlitch

You want the font, supply it. It’ll render properly. Thus it’s not a bug.

I said the same: its a feature. Just clearly tell the buyers about that feature. For the fairness.

Originally Posted by MGlitch

You can pester them ...

I wrote them a very formal report about eight days ago but without feedback. Maybe my report went to the special bin. Can you ask them for clarifications? Maybe they say something to you.

[MGlitch]

Originally Posted by PenguinCEO

I said the same: its a feature. Just clearly tell the buyers about that feature. For the fairness.

I wrote them a very formal report about eight days ago but without feedback. Maybe my report went to the special bin. Can you ask them for clarifications? Maybe they say something to you.

They have previously said you can load your own font. Not including a font isn’t going to be listed for the same reasons “won’t play flash media” won’t be listed. It’s irrelevant.

I have no interest in a monospace font so I won’t ask kobo for it. You know what you need to do to get the performance you want. The idea of this being a bug has been throughly squashed.

[John F]

Just for my own clarification, if I put a proper mono spaced font in the proper font directory, and the book calls for mono spaced font, the mono spaced font will be used?

[jackie_w]

Originally Posted by John F

Just for my own clarification, if I put a proper mono spaced font in the proper font directory, and the book calls for mono spaced font, the mono spaced font will be used?

Not exactly, life's never quite that simple, but that is the first step you'll need to take.

The rest of the workaround/solution is different for kepubs than for epubs. I'm not sure which you use.

For kepub this post has more details. Note: If you're not a kobopatch user miss out step 2, but then you would need to set the Kobo [Aa] font menu to 'Publisher Default' to see the mono font in the book.

For epub the best approach will depend on whether you're also a kobopatch user.

• If you're not a kobopatch user then look at the monospace @font-faces in at the beginning of this ancient post which tells you how to reference a sideloaded font from the CSS inside an epub. You need to include these @font-faces in every epub which needs a mono font. This is tedious if you do it manually but if you're a calibre user you can use the 'Modify CSS' (with kobo_extra.css) option in the calibre KoboTouch driver to do all the work during calibre send-to-device.
• If you are a kobopatch user then life becomes much easier. Just enable the patch called 'Default ePub monospace font (Courier)' customised with the name of your sideloaded mono font of choice. Then you won't need to add any @font-faces to your epubs.

Just for completion, embedding a monospace font in the standard way will work for both kepub and epub.

So, in all, that gives 4 different ways to the same visual result. Whether you like any of them may be another story

[davidfor]

Originally Posted by PenguinCEO

So it's all normal, regular and clear.
The inability of the kobo KA1 to rendering monospaced text out of the box is not a bug: it's a feature.
Well, why Kobo doesn't point out in his web site and on every device box "Beware: This device doesn't supply monospaced type font. It doesn't render monospaced text if fonts are not supplied by the book publisher."
Just for fairness.

Where did I say that it was a feature? What I am saying is that it is not a bug. It is a deficiency, but it is clearly a deliberate choice of Kobo not to supply a monospace font as part of the device.

Why are you losing your temper?

What makes you think I had lost my temper? If I was going to lose my temper, it would be now, but, a statement like this, demonstrates it isn't worth it.

[John F]

Originally Posted by jackie_w

Not exactly, life's never quite that simple, but that is the first step you'll need to take.

The rest of the workaround/solution is different for kepubs than for epubs. I'm not sure which you use.

For kepub this post has more details. Note: If you're not a kobopatch user miss out step 2, but then you would need to set the Kobo [Aa] font menu to 'Publisher Default' to see the mono font in the book.

For epub the best approach will depend on whether you're also a kobopatch user.

• If you're not a kobopatch user then look at the monospace @font-faces in at the beginning of this ancient post which tells you how to reference a sideloaded font from the CSS inside an epub. You need to include these @font-faces in every epub which needs a mono font. This is tedious if you do it manually but if you're a calibre user you can use the 'Modify CSS' (with kobo_extra.css) option in the calibre KoboTouch driver to do all the work during calibre send-to-device.
• If you are a kobopatch user then life becomes much easier. Just enable the patch called 'Default ePub monospace font (Courier)' customised with the name of your sideloaded mono font of choice.

Just for completion, embedding a monospace font in the standard way will work for both kepub and epub.

So, in all, that gives 4 different ways to the same visual result. Whether you like any of them may be another story

Let me rephrase...

For epubs, with stock firmware, no special config file settings, no patches... If a font family of monospaced is specified in the epub, and I put a monospaced font in the "fonts" directory, will the font get used?

I want to know if I purchase an epub that specifies a non-embedded monospace font, the monospaced font will be used (with no modifications needed).

[jackie_w]

Originally Posted by John F

Let me rephrase...

For epubs, with stock firmware, no special config file settings, no patches... If a font family of monospaced is specified in the epub, and I put a monospaced font in the "fonts" directory, will the font get used?

I want to know if I purchase an epub that specifies a non-embedded monospace font, the monospaced font will be used (with no modifications needed).

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.

[JSWolf]

Originally Posted by John F

Let me rephrase...

For epubs, with stock firmware, no special config file settings, no patches... If a font family of monospaced is specified in the epub, and I put a monospaced font in the "fonts" directory, will the font get used?

I want to know if I purchase an epub that specifies a non-embedded monospace font, the monospaced font will be used (with no modifications needed).

Yes, it is a bug that monospace does not work. Even if it was that simple to just load a monospace font with a specific name to fonts, there are many people who would not know to do it.

The reason it's a bug is because a monospace font is part of ADE (RMSDK) and Kobo has chosen to leave this out. This means that monospace does not work when it should work. I don't know of any other RMSDK (ADE) that does not work with monospace out of the box. If it was not part of RMSDK, then fair enough, it is and Kobo changed it so monospace does not work.

[Rev. Bob]

Originally Posted by davidfor

Wrong. If you use "font-family: monospace" and supply an appropriate font, it will work. As it works, it is NOT a bug.

And for the record, this is like saying Windows has a bug because I specified to use "Some Stupid Font" in a book but did not supply the font so that the application could read the font from.

Mark your calendars, folks…

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

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:

All five generic font families must always result in at least one matched font face, for all CSS implementations.

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

Now, that said… yes, in an ebook environment, it is good practice to embed any specific font you want to use. If you want some of your text to be rendered in Georgia, some in Helvetica, another part in Zapfino for cursive or handwriting… yes, by all means, include those specific typefaces. I’d never advise otherwise.

But the whole reason those defaults exist is that, if you want a serif font but aren’t picky about which one, you can specify “serif” and rely on the system default. And the same thing goes for “monospace.”

[MGlitch]

Originally Posted by Rev. Bob

Mark your calendars, folks…

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

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.

Now, that said… yes, in an ebook environment, it is good practice to embed any specific font you want to use. If you want some of your text to be rendered in Georgia, some in Helvetica, another part in Zapfino for cursive or handwriting… yes, by all means, include those specific typefaces. I’d never advise otherwise.

But the whole reason those defaults exist is that, if you want a serif font but aren’t picky about which one, you can specify “serif” and rely on the system default. And the same thing goes for “monospace.”

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

This would seem to indicate otherwise

Originally Posted by DNSB

Hmm... looking at the xhtml code tag: "The code tag is designed to display computer code in a special font, usually in a mono spaced font style. However, the exact appearance will be browser dependent. You may still need to use various HTML tags, such as br and p, to create a presentation and appearance to suit your needs."

To quote: "reading systems are not required to provide the fonts necessary to display every unicode character, though they are required to display at least a placeholder for characters that cannot be displayed fully" (Open Publication Structure 2.0.1).

It would seem “matched” from your quote only means character to character such that a would be a, b to b, and so on down the list rather than style since the device isn’t required to have the font being used only that it provides a substitute.

Which would mean this is, at best, a deficiency, not a bug. As to whether it’s one kobo should rectify I’ll point out I’ve only seen two people actually requesting it on some actual usage level though others have chimed in to ask why Kobo haven’t corrected the deficiency (mistakenly calling it a bug).