Home / Formatting ebooks broken in prereleases

Usher

The last good version is 11040 build. In newer builds there is broken paragraph formatting in ebooks.
See marks on pictures below.

Correct formatting in 11040 build, fixed UI

Errors in 11105 build with fixed UI,

Words divided on accented (Unicode) characters, see marks > on the left margin and < on the right margin. It’s NOT a hyphenation.
Hanging punctuation, see marks >> on the left margin. Hanging punctuation is language independent, it can bee seen also in English text, using only US-ASCII characters.

The same errors in 11105 build with ebook UI:

There are also spaces inserted between different styles in every Sumatra build. See rectangles with hanging punctuation between italic and normal style:

GitHubRulesOK

There have been a few language problems in recent code as a result of trying to improve CJKsupport and Russian is supposedly colateral damaged so may be spilling over to affect the whole world.

Can you link to one of your examples so I can compare with current compile ?

Usher

The changes for CJK are already present in build 11040 which works OK. You can use any non-English epub for Unicode tests and any English epub for punctuation tests. Polish ebooks in public domain you can find on https://wolnelektury.pl/
Just download any epub, open Sumatra prerelease in a normal window, make sure it uses ebook UI, open epub, then slowly resize Sumatra window and watch changes.

If you can’t see italics in your epub files, edit some file in epub and insert something like:
<i>Text in italics</i>, and text normal.

GitHubRulesOK

First one from that link (can’t see italics but issues causing wrapping seem to be addressed

Usher

Well, it looks currently broken formatting has been reported earlier and it’s already fixed: https://github.com/sumatrapdfreader/sumatrapdf/issues/1118

A problem with spacing between styles exist for a long time.

In EbookUI there is probably no additional spacing, though it should be when changing style from italic to normal. On the contrary, in FixedUI there seems to be always positive spacing, though in most cases it should be near to zero.

There may be problem with spacing visibility as it depends on font, its size and metrics. See following examples, watch frames or underlines:

This example was earlier - English text with positive spacing in Fixed UI. Now another piece of the text, Fixed UI, old Sumatra 2.5.2:

Negative or zero spacing in Ebook UI for earlier part of the same text, Cambria 14 pt in use. See bold frames: dot space overlapping on “l” in italic “Russell” and on “s” in italic “lines”.

The same text, Ebook UI, Cambria 24 pt, watch bold frames with “Russell” and “lines” again. There is only one vertical line of pixels overlapped by spacing, I think - compare both “l” letters in “Russell”, and “s” with underlined “s” in italic “us” below.

GitHubRulesOK

@Usher I think the issue you are highlighting here is down to kerning, that is the difference between an italic space and a vertical space. in some cases this would be down to author rather than reader since I have often used both types to modify spacing at ends of sentence. AFAIK there is no hard rule as to which is better or it should be and it will be significantly different when using reflow and justified lines.

I do not dispute there may be differences in handling between versions as a result of word space handling. I suggest since this is a specific use case you raise it on GitHub but please supply a test file that can repeatedly illustrate the differences, as I am unclear as to which type of space is attached to which word.

Usher

I’m not sure whether it’s kerning or spacing. Maybe both, or maybe it’s HTML/css padding or margin attribute in FixedUI. The effect is present between any elements, even using the same style, for italics it’s just better visible.

It’s possible that Sumatra uses different rendering method/engine for e-books in different modes. Or at leasts it uses different default settings.
There are probably zero margins and padding for EbookUI, and no kerning, that’s why normal text overlaps italics.
For FixedUI it looks like limited HTML/css rendering with default positive margin for any tag, even for ignored tags like <span>, which is an inline element and there should be only padding allowed there. BTW. Sumatra ignores also fb2 specific tags rather then replacing them with their HTML/css
equivalents.

Strange, old Calibre viewer for sure uses margins in span – like old Internet Explorer…

So I must play more with different e-book readers and prepare self-explaining e-book with pictures, just need more time.