Adjusting word spacing for justified text – kepub

[JSWolf]

Originally Posted by Sirtel

I made it smaller than default on both my Sage and Libra (-0.06em and -0.07em respectively). But then I don't hyphenate and kerning/ligatures are disabled.

I'm going to try smaller. Would you mind posting either screen caps or photos from both Kobos so I can see which I want to try. Thanks.

[Sirtel]

Originally Posted by JSWolf

I'm going to try smaller. Would you mind posting either screen caps or photos from both Kobos so I can see which I want to try. Thanks.

Photos as requested.

[jackie_w]

Originally Posted by JSWolf

When the code is edited to be just one span in the problematic paragraph, the problem goes away. Just because Kobo does it doesn't mean it's not incorrect.

This sounds too simplistic.

Now I'll admit that my detailed kobospan testing happened several years ago, but I seem to remember that all text needed to be wrapped in a kobospan. Any words that weren't couldn't be highlighted nor could they be looked up in a dictionary.

Did you specifically test these two features after your manual edits? or did you only look at text appearance, i.e. word/letter spacing?

[MGlitch]

Originally Posted by jackie_w

This sounds too simplistic.

Now I'll admit that my detailed kobospan testing happened several years ago, but I seem to remember that all text needed to be wrapped in a kobospan. Any words that weren't couldn't be highlighted nor could they be looked up in a dictionary.

Did you specifically test these two features after your manual edits? or did you only look at text appearance, i.e. word/letter spacing?

AFAICT Jon did what he typically does, had someone else try this out. Of course what is conveniently being left out is that that user also uses patches, including I believe your word spacing one, and the WebKit config file option. Oh and that this user has had a problematic device for awhile though I’m not sure if they got a replacement yet.

So it’s not even a case of removing kobo spans resolved the issue. It’s removing them and taking several other steps seems to have done so in a single test case which was extremely limited being that it was one passage from one ebook of one user.

I may be wrong, though given that Jon is only now pronouncing this as a fix rather than at any point before when kobo spans were mentioned makes me suspect I’m correct.

[JSWolf]

Originally Posted by jackie_w

This sounds too simplistic.

Now I'll admit that my detailed kobospan testing happened several years ago, but I seem to remember that all text needed to be wrapped in a kobospan. Any words that weren't couldn't be highlighted nor could they be looked up in a dictionary.

Did you specifically test these two features after your manual edits? or did you only look at text appearance, i.e. word/letter spacing?

After reading your post, I did some quick tests and dictionary lookup works no problem.

Highlighting does not work properly.

[icallaci]

I tested both "geometricprecision" and "geometricPrecision" but couldn't see any difference between them. Granted, my test case wasn't large. I found a page in my current read that showed larger-than-usual spaces between words, changed webkitTextRendering from "geometricprecision" to "geometricPrecision" in the config file, restarted the Kobo, and looked at the same text. No difference. geometricprecision is definitely better than optimizelegibility, which displayed large spaces between letters in some words, i.e., "T he qu i ck b r o w n fo x..." Now I am wondering if geometricprecision does anything at all. Maybe I'm seeing Kobo's default kepub rendering? The next time I run across odd spacing, I'll remove the webkitTextRendering line altogether and see if anything changes--unless someone has already compared geometricprecision to Kobo's default kepub rendering and can verify that it actually does something?

[rtiangha]

Originally Posted by icallaci

I tested both "geometricprecision" and "geometricPrecision" but couldn't see any difference between them.

That's because the option's value is not case sensitive. You could even write it as geOMeTricPrecIsion and it would yield the same result. That said, who knows if Kobo's webkit renderer supports the option properly.

[icallaci]

Thanks, that's good to know. I did have a chance to compare the difference between Kobo's default rendering and that of geometricPrecision. It appears that the default kepub rendering adds spaces between whole words only, while geometricPrecision adds spaces both within and between words. When geometricPrecision adds spaces between the letters of a word, the spaces seem less drastic than the spaces caused by optimizeLegibility. Again, this is with a very small test case, so your mileage may vary. For now, I much prefer the rendering done by geometricPrecision to both optimizeLegibility and Kobo's default.

Originally Posted by rtiangha

That's because the option's value is not case sensitive. You could even write it as geOMeTricPrecIsion and it would yield the same result. That said, who knows if Kobo's webkit renderer supports the option properly.

[davidfor]

Originally Posted by JSWolf

It's most likely a bug in the renderer.

Yes, it is probably a bug in the renderer. And as it is being discussed so much here, I am sure that you and several others have reported it to Kobo so that they know it is a problem and that people think it is an important problem.

But...

But if it works to render the text correctly with just one koboSpan,

Prove it. Can you please point to where in the kepub specs for rendering where it is defined how characters in this situation should work?

And don't just say, "Because it shouldn't look like that." Because, according to you, there are a lot of things done that are bugs but others think are just fine or even the preferred way to do it. Spaces between paragraphs is a simple example.

why not give it a go?

Yes, that's the attitude. Give it a go. And post the code you develop over in the appropriate thread or as a pull request in the Github repository.

Sorry, oh you mean, "Why don't you, @davidfor, go and write the code to do this?" Why not? Because I have lots of things more important to do than to pander to your little demands like this. Because I have already explained why it hasn't been done and you, as usual, pay completely and utterly no attention to what anyone else thinks. And, honestly, just because I don't feel like it and am not interested in this relatively rare issue. Just think, how long has the driver been around and how often has this been noticed?

And for the record, it will not be as easy as you obviously think. This is exception code. By that I mean it is something that happens unusual circumstances. That means that getting it right can be a lot harder. It means you have to work out what the exceptional circumstance is. What to do in that circumstance. And if there is a similar circumstance that should not be treated this way. And then it cascades because you look at all the other exceptions. And all this will lead to slower, harder to maintain code to cover something that, apparently, rarely happens.

I have said I will look at @jackie_w's code for doing one span per paragraph when I have time. That should solve this and other similar issues. Coding something more specific is a waste of time if that is going to happen.

[JSWolf]

Originally Posted by icallaci

Thanks, that's good to know. I did have a chance to compare the difference between Kobo's default rendering and that of geometricPrecision. It appears that the default kepub rendering adds spaces between whole words only, while geometricPrecision adds spaces both within and between words. When geometricPrecision adds spaces between the letters of a word, the spaces seem less drastic than the spaces caused by optimizeLegibility. Again, this is with a very small test case, so your mileage may vary. For now, I much prefer the rendering done by geometricPrecision to both optimizeLegibility and Kobo's default.

I've not had any added spaces within words with geometricPrecision or optimizeLegibility.

[icallaci]

Originally Posted by JSWolf

I've not had any added spaces within words with geometricPrecision or optimizeLegibility.

I'm reading kepubs on a patched Ellipsa. The spaces within words using geometricPrecision are much subtler than with optimizeLegibility, but the spaces are definitely there. The most noticeable cases occur immediately before a span (not necessarily a kobospan; italics or bold also cause the problem). I'm satisfied with the way geometricPrecision handles it, so I won't be delving into it any further. I'd rather read.

[ZodWallop]

For me, geometricPrecision, the word-spacing patch and the better hyphenation dictionary has put the kepub renderer nearly on par with the ePub renderer

[JSWolf]

Originally Posted by icallaci

I'm reading kepubs on a patched Ellipsa. The spaces within words using geometricPrecision are much subtler than with optimizeLegibility, but the spaces are definitely there. The most noticeable cases occur immediately before a span (not necessarily a kobospan; italics or bold also cause the problem). I'm satisfied with the way geometricPrecision handles it, so I won't be delving into it any further. I'd rather read.

I convert italics and bold that are done with spans into <i> and <b>. Could this be why I am not seeing this spacing irregularity?

The KePub I am reading now, I've made no changes to since the KTE driver converted it.

[MGlitch]

Originally Posted by ZodWallop

For me, geometricPrecision, the word-spacing patch and the better hyphenation dictionary has put the kepub renderer nearly on par with the ePub renderer

What does the epub renderer do better compared to the kepub renderer with those modifications? Actually asking, as I thought they basically brought everything to the kepub renderer that it was lacking or deficient in.

[ZodWallop]

Originally Posted by JSWolf

I convert italics and bold that are done with spans into <i> and <b>.

How do you easily do that?

The opening tag is easy enough to search and replace. But finding which </span>s are bold or italic vs. something else can be a headache.