Kepub format questions

[Semwize]

Originally Posted by davidfor

From memory, using a non-break space was one of the suggestions to improve things.

It does not help.

The only way out is to not use kepub. At all.

When creating kepub, Kobo did not think about other typography, and about other languages used. Just idiocy.

[DNSB]

Originally Posted by Semwize

It does not help.

The only way out is to not use kepub. At all.

When creating kepub, Kobo did not think about other typography, and about other languages used. Just idiocy.

It would be more that a bit difficult to handle epubs using Japanese typography with the RMSDK renderer. Both renderers used have some issues but nothing that is what I would call a show stopper.

[Gorcsev]

Originally Posted by Semwize

It does not help.

The only way out is to not use kepub. At all.

When creating kepub, Kobo did not think about other typography, and about other languages used. Just idiocy.

en-space instead of non-breaking after the dash helps
en-space is a fix length space non-breaking space is not ( at least after an en-dash)

[jackie_w]

Originally Posted by Gorcsev

Unfortunately you are right it was discussed earlier, but as I read through that post it was not a settled down solution. As I searched the net, the non-break space is not 100% means "not-variable length space". Better solution (I tried in kepub) would be the fix length "1/4 em-space" but the device displays a □ when the "text-rendering: optimezedlegibility/speed" is used in body tag.

Interim solution a fix length "en-space" but again, it means should be touched all the books what I sideload to KOBO .

There are 3 (at least) different things to consider here when trying to "beautify" full-justified text:

1. Font used: The problem with using some of those 'special spaces' is that most freely available fonts don't actually contain those glyphs (e.g. U+2003, U+2004, U+2005), so you see the generic 'glyph unavailable' character instead. Did you check that? I'd be surprised if any of the built-in fonts have them.
   
   Even if you do find a suitable font to sideload you may still suffer the 'stretchy spaces' problem. If a non-breaking-space doesn't work is there any reason to believe one of the other spaces will be any better?
   
   
2. Hyphenation: Hungarian isn't one of Kobo's officially supported languages so they don't supply a hyph_hu.dic hyphenation dictionary. Have you been able to install a custom one? Do you see any hyphenation in your Hungarian books?
   
   I know it's easy to replace the Kobo default English hyphenation dictionary with a better one but I'm not sure whether there's more to it when adding a new language.
   
   
3. koboSpans algorithm: If you're comfortable hacking your own copy of KTE ... Rather than trying to decide "when is a sentence not a sentence", just don't split into sentences at all. Try this simple hack to greatly reduce the number of koboSpans added.
   
   Inside the KoboTouchExtended.zip file find the container.py file, change lines 540-544 from
   

                   groups = re.split(
                       r'(.*?[\.\!\?\:][\'"\u201d\u2019“…]?\s*)',
                       text,
                       flags=re.UNICODE | re.MULTILINE,
                   )

   to
   

                   groups = [text]

   This is the first hack I was referring to in post #60. It has the benefit of being language independent, but I can't promise there won't be unintended consequences with annotations and bookmarking. You'll need to experiment.

I know you would prefer to use kepub but did you actually test whether all the problems disappear if you use epub?

Is it possible you could post a 1-page test epub containing the kind of HTML you see when you buy a retail Hungarian book with a lot of dialogue? I'm having difficulty understanding whether your problems are with the original epub or with a manually edited version. There's not much likelihood of successfully hacking KTE to auto-edit books on-the fly if no-one knows what the original HTML looks like.

[Gorcsev]

Font used:

I made a trial and en-space seems working and keeps the length as I see .(and the default built in font shows a space not any replacement char)


Hyphenation:

For hyphenation i found out the following process:
It is installed long time ago in my Calibre the "Hyphenate this" plugin, with Hungarian hyphenation dictionary. It does the job well (on epub and on azw). So first hyphenate my epub, after sending it to KOBO (KTE, kepub) and it works


koboSpans algorithm:
Thank you the code . I will make some test with it

I just wanted starting using kepub... Its a good challenge :-)

[Gorcsev]

Originally Posted by jackie_w

Kepubs do support both ligatures and kerning if you add the right line of CSS - body {text-rendering: optimizeLegibility;}- either by hand, via calibre driver or via patch. Ligatures/kerning will only be as good as the font you're using.

please how do I add that tag via calibre driver?

and is it possible to change my

p.center {
display: block;
text-align: center;
margin-top: 0;
text-indent: 0;
line-height: 130%;
widows: 2;
orphans: 2;
}

to that only with the same way?

p.center * {
display: block;
text-align: center !important;
margin-top: 0;
text-indent: 0;
line-height: 130%;
widows: 2;
orphans: 2;
}

adding the star and the !important to the existing tags

thank you

[davidfor]

Originally Posted by Gorcsev

please how do I add that tag via calibre driver?

and is it possible to change my

p.center {
display: block;
text-align: center;
margin-top: 0;
text-indent: 0;
line-height: 130%;
widows: 2;
orphans: 2;
}

to that only with the same way?

p.center * {
display: block;
text-align: center !important;
margin-top: 0;
text-indent: 0;
line-height: 130%;
widows: 2;
orphans: 2;
}

adding the star and the !important to the existing tags

The driver has an option to modify the CSS. It appends the contents of a CSS fileto all stylesheets in the book. As long as it is valid CSS, it should work. The file is called "kobo_extra.css" and needs to be put in the root partition of the device. I think all you want in the file is:

p.center  {
  text-align: center !important;
}

I'm minimising what I think is needed, as, f I understand it, I'm not sure that "p.center *" makes sense as a selector. That's because I can't think of any tag that could be contained in a "p" that setting text-align to center makes sense. But, I'll make no claim about being an expert on CSS. If I'm wrong, then putting the full block you have should work.

[Gorcsev]

Originally Posted by davidfor

The driver has an option to modify the CSS. It appends the contents of a CSS fileto all stylesheets in the book. As long as it is valid CSS, it should work. The file is called "kobo_extra.css" and needs to be put in the root partition of the device.

thank you

during the time I have found that the kobo_extra_DEVICE.css could be in the plugin directory as well

As I saw each KOBO should have different name convention in this file.

How should I name the file for Clara _CLARAHD ? Or just using the _GLOHD

[davidfor]

Originally Posted by Gorcsev

during the time I have found that the kobo_extra_DEVICE.css could be in the plugin directory as well

As I saw each KOBO should have different name convention in this file.

How should I name the file for Clara _CLARAHD ? Or just using the _GLOHD

The file has to be in the root directory of the device. And is called "kobo_extra.css" This is function supplied by the KoboTouch driver.

The KoboTouchExtended driver extends the function of the KoboTouch driver. In this case, it can copy the file from elsewhere and put it on the device. As you discovered, it looks for a file with the device name added to it. But, it looks like that part hasn't been updated for a while as it doesn't have the Aura ONE or later defined. It should be OK just to use "kobo_extra.css" in the plugin directory or put it on the device.

[Gorcsev]

Originally Posted by jackie_w

Inside the KoboTouchExtended.zip file find the container.py file, change lines 540-544 from

                groups = re.split(
                    r'(.*?[\.\!\?\:][\'"\u201d\u2019“…]?\s*)',
                    text,
                    flags=re.UNICODE | re.MULTILINE,
                )

to

                groups = [text]

Thank you i was made lots of trials until now. What I realized:
this method above is ok, until the text do not have any direct formatting tag inside the sentence. for example: <i>, or <b> or even a <br/> what is newline, and so on. Somehow the procedure is handling those tags separated, and puts spans around them.

I think this is a "calibre" behavior. It makes class from any single <i>... tags a <i span class="calibrexx"... and that generates the above mentioned code

Do you know any bypass code for that to insert into the kte somewhere?

For example change the <i> to a @lti@gt , process the "spanning" and change back to the original.

So the sentence would be kept, and not split with spans.

the best would be bypass any "calibre-ish" convert, just let the epub as it is, and send it to the device "kepub-ized"...

thank you

[jackie_w]

Originally Posted by Gorcsev

Thank you i was made lots of trials until now. What I realized:
this method above is ok, until the text do not have any direct formatting tag inside the sentence. for example: <i>, or <b> or even a <br/> what is newline, and so on. Somehow the procedure is handling those tags separated, and puts spans around them.

I think this is a "calibre" behavior. It makes class from any single <i>... tags a <i span class="calibrexx"... and that generates the above mentioned code

Do you know any bypass code for that to insert into the kte somewhere?

For example change the <i> to a @lti@gt , process the "spanning" and change back to the original.

So the sentence would be kept, and not split with spans.

the best would be bypass any "calibre-ish" convert, just let the epub as it is, and send it to the device "kepub-ized"...

thank you

The decision to create koboSpans for <i>, <span>, <br/> etc is Kobo's. It's nothing to do with calibre. If you look at a purchased kepub from the Kobo bookstore you will see that a koboSpan is only ever wrapped around plain text, it never contains other tags.

The KTE plugin honours that decision and so does the one-line hack I posted. All the hack does is reliably reduce the number of koboSpans to one-per-node, rather than one-per-sentence. Inline tags such as <i>, <span>, <br/> etc are all nodes therefore a koboSpan is created.

It sounds like you'd prefer to change the koboSpan algorithm to one-per-paragraph. If so you'll need to figure out how to do that yourself. I doubt that it's a simple hack, given the variety of weird HTML markup that exists in the wild. On the other hand, developing something that works well enough with your own epubs is always easier than developing something that would also work well for everyone else.

Good luck!

[Gorcsev]

Originally Posted by jackie_w

It sounds like you'd prefer to change the koboSpan algorithm to one-per-paragraph. If so you'll need to figure out how to do that yourself. I doubt that it's a simple hack, given the variety of weird HTML markup that exists in the wild. On the other hand, developing something that works well enough with your own epubs is always easier than developing something that would also work well for everyone else.

Good luck!

thank you

Unfortunately what are the kepub expectations for the best rendering result is not very well documented. I understood during debug the KTE, that it handles the nodes, and the elements (plus the child elements...) separately and so creates the SPANS.
I am fully appreciated about your shared code. I played a lot with it as well.
My goal is to find out, what would be the best looking rendered result. (btw. If there is no tags between the <p></p>, Your hack does the same --> one spans per paragraph).
I simple wanted try out what is better: having long untouched texts or split them.
Having all my full appreciation for the KTE developer, I would like to ask, is that also a KOBO requirement to flatten the CSS, like calibre does?
I mean the calibre generated classes everywhere, instead of using the p+p, or h+p... approach for handling the paragraphs.

[jackie_w]

Originally Posted by Gorcsev

Having all my full appreciation for the KTE developer, I would like to ask, is that also a KOBO requirement to flatten the CSS, like calibre does?
I mean the calibre generated classes everywhere, instead of using the p+p, or h+p... approach for handling the paragraphs.

I think maybe there is some confusion here. Whether it's mine or yours I'm not sure Classes being added to every tag, even <i>, <br/> etc, is a function of a full calibre conversion (FROM any format TO any format). This is unavoidable. KTE never does a full conversion to kepub, it only does a format-shift from epub to kepub. If your source epub contains CSS like p+p KTE should leave it there in the kepub transferred to the Kobo. Similarly KTE does not add classes to simple <i>, <br/> tags.

Originally Posted by Gorcsev

I simple wanted try out what is better: having long untouched texts or split them.

The simplest way to check this out may be to do a temporary hack to your KTE to comment-out adding koboSpans altogether. If you then use KTE to transfer a single epub as kepub you can look at the effect on the text appearance of having long completely untouched texts. If it improves the "look" of your books you would know that it might be worth pursuing the one-per-paragraph koboSpan.

I don't think you would want to leave the "no koboSpans" hack in place as I seem to remember it will remove some of the kepub functionality e.g. highlighting, search in book and also I can't remember what it does to the Kobo's ability to remember book progress between sessions. I think dictionary lookup still works, though.

However, who am I to make that judgement? If you don't need any of the above, "no koboSpans" is a much easier reliable hack than one-per-paragraph.

[Gorcsev]

Originally Posted by jackie_w

I think maybe there is some confusion here. Whether it's mine or yours I'm not sure Classes being added to every tag, even <i>, <br/> etc, is a function of a full calibre conversion (FROM any format TO any format). This is unavoidable. KTE never does a full conversion to kepub, it only does a format-shift from epub to kepub. If your source epub contains CSS like p+p KTE should leave it there in the kepub transferred to the Kobo. Similarly KTE does not add classes to simple <i>, <br/> tags.

It can be I am confused, while made trials with KTE and KepubOutput parallel.
It is from same developer, (the codes are almost identical) and I didn't wanted copy force and back the sent kepubs from KOBO for checking the result. As in debug I didn't found a place where to stop the code before sending it to device.
Could be that the kepub output makes the "flattening css" and the kte is not flattening. I will try

[Gorcsev]

The confusion was on my side.

The KTE itself not flatten the output, not generates the calibre classes, just make a nice kepub on the device.

jackie_w thank you for let me realize my mistake