Aura ONE "monospace" rendering

[dmapr]

Originally Posted by DNSB

What monospace bug in RMSDK? RMSDK will happily display a monospaced font if one is available on the device.

I think the bug is mentioned in the patch notes and it's not that the font is missing, it's that placing the font there without a patch will not work. I haven't tested that in the latest firmware though.

Kobo devices don't come with any monospace fonts. If the book's stylesheet specifies font-family:monospace; then the ePub reader will try to use the "Courier Std" font, but even if that font were installed it wouldn't work because the pathnames used by the ePub reader to request the font are wrong.

[MGlitch]

Originally Posted by PenguinCEO

Where browsers and unicode come out? The object of this thread is completely different.

Change browser to reader, in this case since the Kobo doesn’t have a monospace font to use it doesn’t use one.

Provide it one by either embedding and using publishers defaults, or load a monospace font of your choice and patch the firmware to use it.

Boom monospace displays correctly meaning this isn’t a bug it’s Kobo not choosing to license a monospace font. No standard mentioned or quoted thus far requires them to do so.

[Quoth]

Which is weird as Kobo uses Linux and Linux does have several "free" monospace fonts.

[DNSB]

Originally Posted by PenguinCEO

Where browsers and unicode come out? The object of this thread is completely different.

If I had used renderer for browser would you have been happier?

You do realize that the subset of CSS used for epub is inherited from that used by web browsers with a few minor additions?

As for Unicode, epubs are required to use either UTF-8 (a variable width character encoding capable of encoding all 1,112,064 valid code points in Unicode using one to four 8-bit bytes) or UTF-16.

And, again to quote from the Epub specifications:

3.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 recommended 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.

Basically, we seem to agree that having a monospace font is desirable. Where we differ is that you want to call the lack of a monospace font a bug and are not willing to look at the workarounds that will correct the issue.

’Nuff said.

[ratinox]

Originally Posted by FrustratedReader

Which is weird as Kobo uses Linux and Linux does have several "free" monospace fonts.

And they're all terrible. I find Cousine to be less terrible than most and that's what I use in my xterms but I have yet to find a monospaced typeface that doesn't look garbage on small devices.

[Sam Sahara]

Originally Posted by DNSB

... You do realize that the subset of CSS used for epub is inherited from that used by web browsers with a few minor additions? ...

I don't understand why so much theory for a so simple fact:

Attachment 174724

Attachment 174725

I see that monospace is badly rendered; now it is formatting's fault or it is device's fault. Tertium non datur. I understand that the formatting has no problems at all. So the problem is into the device.

[ratinox]

Originally Posted by Sam Sahara

I see that monospace is badly rendered; now it is formatting's fault or it is device's fault. Tertium non datur. I understand that the formatting has no problems at all. So the problem is into the device.

None of the above because it's not a rendering problem at all.

HTML and CSS are text markup languages. They tell the renderer what to make individual characters (text) look like. Which, in fact, your examples show happening correctly. They don't (and can't) tell the renderer what the whole page looks like. For this you need a page description language like PDF.

[Sam Sahara]

Originally Posted by ratinox

HTML and CSS are text markup languages. They tell the renderer what to make individual characters (text) look like. Which, in fact, your examples show happening correctly. They don't (and can't) tell the renderer what the whole page looks like. For this you need a page description language like PDF.

What? What does that have to do with the thread matter? How many Kobo employees are there on this forum?

[ratinox]

Originally Posted by Sam Sahara

What? What does that have to do with the thread matter? How many Kobo employees are there on this forum?

Question: "Is there something to do to solve this problem?"

Answer: HTML and CSS cannot do precise page layout. They just can't. You need to use a page description language like PDF.

[davidfor]

Originally Posted by Sam Sahara

What? What does that have to do with the thread matter?

As far as I can tell, your code is rendered perfectly. Within the bounds of the capability of the device and what you supplied. The device does not include a monospace font and there is nothing in any standards that state that it must. If you have a need for a monospace font in a book, you need to supply the font. And set it up correctly in the book.

The alternative is to change to a format that allows precise positioning, such as PDF. Or embed an image that does what you want. Possibly an SVG image would be the way to go.

How many Kobo employees are there on this forum?

This is not an official support forum for Kobo. If there are any Kobo employees here, they are not here as Kobo employees.

[DNSB]

Originally Posted by Sam Sahara

I don't understand why so much theory for a so simple fact:

I see that monospace is badly rendered; now it is formatting's fault or it is device's fault. Tertium non datur. I understand that the formatting has no problems at all. So the problem is into the device.

1. If you look at your copies of those images, you will notice that they are not using a monospaced font. Otherwise 'violet' would look like 'violet' -- pay attention to the extra space around the 'i' and 'l' and the even spacing between the letter center lines.
   
2. There is no requirement in either the epub2 or epub3 specs to have a monospaced font available.
   
3. Would it be nice to have a monospaced font? Yes. Is it a bug not to have a monospaced font? No.

Originally Posted by Sam Sahara

What? What does that have to do with the thread matter? How many Kobo employees are there on this forum?

Very much to do the post you linked to. He is attempted to align text without using a monospace font. He rejected any suggestions/workarounds with whinging that he paid "all good money" and it's a bug that his Kobo does not have a monospaced font.

As for how many Kobo employees? If any Kobo employees are reading these forums, they are not doing so as Kobo employees. Contrary to what some people seem to think, this is not an official or even unofficial, Kobo support forum.

[rtiangha]

Just curious: Does anyone know what the incorrect path that the Adobe renderer is expecting to find CourierStd on the Kobo actually is? I'd like to see if flashing a copy there would work, just for fun.

[jackie_w]

Originally Posted by rtiangha

Just curious: Does anyone know what the incorrect path that the Adobe renderer is expecting to find CourierStd on the Kobo actually is? I'd like to see if flashing a copy there would work, just for fun.

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

[rtiangha]

Originally Posted by jackie_w

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

Ah, I see. I'm guessing that the Kobo doesn't know how to resolve the res:// part to point to either /mnt/onboard/fonts or /usr/local/Trolltech/QtEmbedded-4.6.2-arm/lib/fonts then. Bummer. Unless it's a relative path to where the Adobe executable lies. Or if it follows the same convention as ADE, then its preferred fonts directory might be at the same location and level where it accesses its Hyphen Dictionaries. Does anyone know if that's still /usr/local/Kobo/hyphenDicts? If so, then might be able to get away with sticking CourierStd and any other standard Adobe Reader fonts in /usr/local/Kobo/fonts. There's also /usr/share/hyphen, but they're all empty files (unless they're meant to be sym links; can't tell on Windows). So /usr/share/fonts might be another candidate.

[jackie_w]

Originally Posted by rtiangha

Ah, I see. I'm guessing that the Kobo doesn't know how to resolve the res:// part to point to either /mnt/onboard/fonts or /usr/local/Trolltech/QtEmbedded-4.6.2-arm/lib/fonts then. Bummer. Unless it's a relative path to where the Adobe executable lies. Time to start poking around, I guess.

I don't think it works quite like you may think. For example, the same links, which do work correctly, which define how font-family:sans-serif should be rendered (standard epubs) are:
res:///fonts/normal/Avenir
res:///fonts/bold/Avenir
res:///fonts/italic/Avenir
res:///fonts/bolditalic/Avenir

I'm loathe to volunteer much more in case I divert you from having a new and better "good idea" no-one else has tried yet

You probably know this already, but there is already a kobopatch which fixes the incorrect monospace stuff but, because it's hacking, not everyone wants to use it. A solution which could be achieved just by copying files to the "right place" may be more acceptable to more people.