https://bugs.freedesktop.org/show_bug.cgi?id=57652
--- Comment #9 from stfhell <[email protected]> --- (In reply to comment #8) > As far as I understand, when the line is not maximally packed with text, > word joiner behave correctly. The problems start near full density of text; > then calculations go wrong. I don't think so. The keep-together "Cra s" in your test file seems stable, even if you add more text to the end, so that it will be justified. It seems that the presence of some characters in the paragraph (here WJ, in Bug 56392 the quotation mark) prevents the line breaker from realizing some line break opportunities. > In the breakiterator source code the u+2060 character is referred only once, > as “special case” at the final stage of analysis. I suspect this piece was > programmed as a kind of patch, but I am afraid it does not play its role in > general case. Are you sure if BreakIterator_Unicode::getLineBreak() is really used here? There are so many parallel solutions for the same things in LO, maybe getLineBreak() is only used with CTL, Asian writing systems or again something else. The function looks strange to me anyway, as it sets the Boolean "GlueSpace=sal_True" before a "while (GlueSpace)" loop without any "return", "break" or "GlueSpace=sal_False". But I haven't looked too closely. WJ could also be covered in the database- or rule-driven approach (see file i18npool/source/breakiterator/data/line.txt). -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
