Issue 26519 - Attribute change in text breaks kerning
Summary: Attribute change in text breaks kerning
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: OOo 1.1.1RC
Hardware: PC All
: P4 Trivial (vote)
Target Milestone: AOO PleaseHelp
Assignee: AOO issues mailing list
QA Contact:
Keywords: oooqa
Depends on: 94493
  Show dependency tree
Reported: 2004-03-15 22:38 UTC by diamondtm
Modified: 2017-05-20 11:30 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

Kerning pairs with different colors - Arial font (5.23 KB, application/vnd.sun.xml.writer)
2004-03-20 09:04 UTC, diamondtm
no flags Details
Patch for the issue (4.22 KB, patch)
2009-08-13 15:16 UTC,
no flags Details | Diff
another reduced testdoc (15.14 KB, application/vnd.oasis.opendocument.text)
2009-09-02 16:38 UTC,
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description diamondtm 2004-03-15 22:38:50 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: "" 
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 ;-)
Comment 1 flibby05 2004-03-19 12:22:23 UTC
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
Comment 2 diamondtm 2004-03-20 09:03:29 UTC
Try this : (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.`. 
Comment 3 diamondtm 2004-03-20 09:04:49 UTC
Created attachment 13951 [details]
Kerning pairs with different colors - Arial font
Comment 4 flibby05 2004-03-21 13:53:55 UTC
confirmed with 1.1.1rc3 offical Linux build

see also issue 19380
Comment 5 h.ilter 2004-03-23 13:54:10 UTC
Reassigned to US
Comment 6 ulf.stroehler 2005-05-31 18:15:15 UTC
@submitter/maxweber: pls. try a current snapshot of OO.o and report back whether the
problem still persits or close. Thx.
Comment 7 flibby05 2005-05-31 18:32:45 UTC
us: problem persists with m103 on SuSE 9.3
Comment 8 ulf.stroehler 2005-06-06 15:11:58 UTC
Forwarding to HDU (reproduced on Linux).
Comment 9 2005-06-06 16:04:07 UTC
Comment 10 2005-06-07 13:41:22 UTC
Only on UNX platforms, on WIN it looks ok.
Comment 11 2009-08-13 15:16:04 UTC
Created attachment 64137 [details]
Patch for the issue
Comment 12 2009-08-13 17:05:33 UTC
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.
Comment 13 2009-09-02 16:38:57 UTC
Created attachment 64502 [details]
another reduced testdoc
Comment 14 2009-09-03 15:06:18 UTC
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.
Comment 15 Marcus 2017-05-20 11:30:00 UTC
Reset assigne to the default "".