Apache OpenOffice (AOO) Bugzilla – Issue 26519
Attribute change in text breaks kerning
Last modified: 2017-05-20 11:30:00 UTC
When using a font with kernings it shows OK when both characters of the kerning pair are of the same color. If one character has different color, no kerning is applied. See: "http://194.177.204.125/~thdiaman/kern.png" First line: seperate characters - space between them (OK) Second line: same characters with kernings - black color (OK) Third line: same characters with kernings - red color (OK) Fourth line: first character black, second red (NOT OK) Hope it's something easy to fix ;-)
hello, thank you for using and supporting OpenOffice.Org! Could you please attach a sample document for reproducing your issue? Thank you very much, Max Weber, OOo Volunteer
Try this : http://194.177.204.125/~thdiaman/color_kernings.sxw (or the attachment IF I can make it through the procedure ;-)))))) It uses the Arial font. _Some_ of the Arial kerning pairs are `AT`, `AW`, `AV`, and `F.`.
Created attachment 13951 [details] Kerning pairs with different colors - Arial font
confirmed with 1.1.1rc3 offical Linux build see also issue 19380
Reassigned to US
@submitter/maxweber: pls. try a current snapshot of OO.o and report back whether the problem still persits or close. Thx.
us: problem persists with m103 on SuSE 9.3
Forwarding to HDU (reproduced on Linux).
.
Only on UNX platforms, on WIN it looks ok.
Created attachment 64137 [details] Patch for the issue
Cool! I'll test the patch soon. Caveats are that WriterEngine+EditEngine assume they control exactly where they position their "portions". Since the problem is exactly that the positioning of the portion (an attribute change splits the text into different portions) by Writer+EditEngine is not good enough, I'm a little in doubt that we can solve it at that the VCL-level alone. AFAIK the patch modifies the position of a portion under the radar of WE+EE, which could introduce problems with cursor-positioning, clipping, etc.
Created attachment 64502 [details] another reduced testdoc
Adjusted the summary line to the root cause. The real problem is that Writer-/Edit-Engine feed vcl what to do using their portion concept one portion at a time. A portion is a sequence of unicodes sharing the same text attributes such as font face, font size, justification method, BiDi attributes, font color, background color, underline color, portion position, etc. Since vcl currently only gets to see the exact portion and nothing of the attributes of its neighboring portions it only could take wild guesses of its own. Assuming that text attributes like font face, font size or any other text attributes would probably not change across a portion boundary will certainly introduce new problems, because the assumption is certainly wrong as the portion boundary is there exactly because there was such an attribute change. The proposed patch works by assuming that the font face, font size and the pair-kerning attribute keep unchanged. @od: The best short-term fix is for Writer-/Edit-Engine to adjust the portion positions when the kerning attribute is valid across portion boundaries. They know the position adjustment which is needed for this e.g. by calling GetKerningPairs() or by measuring the layout of multiple joined portions of kerned/unkerned text. There is a better fix in best long term fix though: doing most of the layout near the shaping engines by providing all the details to fully layout a line of text to vcl at once instead of this piecewise feeding. This could also solve such problems as i88539, where Writer tries to do an adjustment between reference device and target device, which has always been an approach that has resulted in highly criticized text layout. VCL currently cannot do anything about this because it cannot distinguish whether awkward positioning is intential (e.g. from tab-spacing) or from a bad adjustment to the reference device.
Reset assigne to the default "issues@openoffice.apache.org".