MobileRead Forums - View Single Post

arspr · 10-30-2013, 05:45 PM

Product: Aura HD (but I think it's irrelevant. I'll explain later)
Firmware: 2.8.1. (b2c05cda0e, 9/20/2013)
Plugins: ???
File types: At least kepubized epubs but I suppose "official" kepubs too
Sideloaded or from Kobobooks: epubs loaded through Calibre as kepubs (KoboTouchExtended Plugin in Calibre)
On external SD: No
Steps to reproduce:

First of all an explanation and context.

In English you usually write conversation paragraphs in this way:

Code:

"Bla, bla, bla," John said. "More bla, bla, bla."

(I've intentionally used code tags because of the bug explanation. I need to put spaces with precision).

But in Spanish books, the same paragraph would be written in this way:

Code:

—Bla, bla, bla, —John said—. More bla, bla, bla.

Please notice that if you have in your hands a well formatted text, it will use dashes not minus signs or small hyphens. I've used long dash ( — or — ), but medium dash is also frequently used ( – or – ). I've checked the issue I'm going to explain at least in a book which uses — , and in a book which uses —.

The problem arises because as the dashes are joined to the word as you can see in the code view (— to the first "Bla", — to "John", — to both "said" and the dot). I mean that dashes are just another punctuation mark; they behave just like dots, commas, semicolons or question marks. They are always "attached" to their partner word.

But Kepub renderer, (at least in Aura HD v.2.8.1), doesn't work in this way. It considers dashes as a "different word".

In this way if you have a justified text with longer spaces between words than usual you end with the following rendering:

Code:

— Bla,  bla,  bla,  — John  said — .  More  bla,  bla,  bla.

(I've put an extra space between "words")

And that rendering is completely weird. The correct one would be:

Code:

—Bla,  bla,  bla,  —John  said—.  More  bla,  bla,  bla.

All my books in my Kobo account are English books, so I cannot confirm if this issue is present in "official" Kepubs. I can only see it in "Kepubized" epubs through Calibre. But I'd bet money that the Kepub source is not relevant at all, that the problem is in the "engine".

Side note:

Within the pure epub renderer, i.e. ADE renderer, this bug doesn't happen. BUT there's another different issue that exists even in my old Sony PRS-650. And I suppose that this issue ALSO happens within Kepub renderer. (I haven't checked).

Dashes are "wrongly" considered "wrap points". So in a sentence like the previous one you can end with:

Code:

—Bla, bla, bla, —
John said—. More bla, bla, bla.

or even with:

Code:

—Bla, bla, bla, —John said
—. More bla, bla, bla.

As a workaround for this issue within ADE I always unDRM and edit my Spanish epubs and then I change the conversation paragraph code into:

Code:

<p>—Bla, bla, bla, <span style:"white-space:nowrap">—John</span> <span style:"white-space:nowrap">said—.</span> More bla, bla, bla.</p>

(I do it through Regex searches...)

But this workaround doesn't avoid the "extra" middle space within kepub renderer...

Current result: Explained above
Workaround: I don't know any. (Ideas are welcome

)

10-30-2013, 05:45 PM	#298
arspr Dead account. Bye Posts: 587 Karma: 668244 Join Date: Mar 2011 Device: none	Product: Aura HD (but I think it's irrelevant. I'll explain later) Firmware: 2.8.1. (b2c05cda0e, 9/20/2013) Plugins: ??? File types: At least kepubized epubs but I suppose "official" kepubs too Sideloaded or from Kobobooks: epubs loaded through Calibre as kepubs (KoboTouchExtended Plugin in Calibre) On external SD: No Steps to reproduce: First of all an explanation and context. In English you usually write conversation paragraphs in this way: Code: "Bla, bla, bla," John said. "More bla, bla, bla." (I've intentionally used code tags because of the bug explanation. I need to put spaces with precision). But in Spanish books, the same paragraph would be written in this way: Code: —Bla, bla, bla, —John said—. More bla, bla, bla. Please notice that if you have in your hands a well formatted text, it will use dashes not minus signs or small hyphens. I've used long dash ( — or — ), but medium dash is also frequently used ( – or – ). I've checked the issue I'm going to explain at least in a book which uses — , and in a book which uses —. The problem arises because as the dashes are joined to the word as you can see in the code view (— to the first "Bla", — to "John", — to both "said" and the dot). I mean that dashes are just another punctuation mark; they behave just like dots, commas, semicolons or question marks. They are always "attached" to their partner word. But Kepub renderer, (at least in Aura HD v.2.8.1), doesn't work in this way. It considers dashes as a "different word". In this way if you have a justified text with longer spaces between words than usual you end with the following rendering: Code: — Bla, bla, bla, — John said — . More bla, bla, bla. (I've put an extra space between "words") And that rendering is completely weird. The correct one would be: Code: —Bla, bla, bla, —John said—. More bla, bla, bla. All my books in my Kobo account are English books, so I cannot confirm if this issue is present in "official" Kepubs. I can only see it in "Kepubized" epubs through Calibre. But I'd bet money that the Kepub source is not relevant at all, that the problem is in the "engine". Side note: Within the pure epub renderer, i.e. ADE renderer, this bug doesn't happen. BUT there's another different issue that exists even in my old Sony PRS-650. And I suppose that this issue ALSO happens within Kepub renderer. (I haven't checked). Dashes are "wrongly" considered "wrap points". So in a sentence like the previous one you can end with: Code: —Bla, bla, bla, — John said—. More bla, bla, bla. or even with: Code: —Bla, bla, bla, —John said —. More bla, bla, bla. As a workaround for this issue within ADE I always unDRM and edit my Spanish epubs and then I change the conversation paragraph code into: Code: <p>—Bla, bla, bla, <span style:"white-space:nowrap">—John</span> <span style:"white-space:nowrap">said—.</span> More bla, bla, bla.</p> (I do it through Regex searches...) But this workaround doesn't avoid the "extra" middle space within kepub renderer... Current result: Explained above Workaround: I don't know any. (Ideas are welcome )