Bug Hunting Session
Bug 61444 - Text layout broken across formatting changes (color, underline, etc.)
Summary: Text layout broken across formatting changes (color, underline, etc.)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 107155 111631 117535 124347 (view as bug list)
Depends on:
Blocks: Font-Rendering 124116
  Show dependency treegraph
 
Reported: 2013-02-25 13:53 UTC by Stefan Knorr (astron)
Modified: 2019-03-27 17:46 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Test document (11.59 KB, application/vnd.oasis.opendocument.text)
2013-02-25 13:53 UTC, Stefan Knorr (astron)
Details
Sanple Document with WIN screenshots (147.86 KB, application/vnd.oasis.opendocument.text)
2013-02-25 17:11 UTC, Rainer Bielefeld Retired
Details
Screenshot OpenSUSE 12.2 (30.85 KB, image/png)
2013-02-25 21:31 UTC, Stefan Knorr (astron)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Knorr (astron) 2013-02-25 13:53:47 UTC
Created attachment 75506 [details]
Test document

When changing the text color between two adjacent letters of the same text size, same font, etc., the kerning between the letters is removed.

See the test document: the second AV is spaced far wider apart than the first one.

There seems to be no good technical reason for this particular behaviour – although I understand that this has to happen when using different font files [like bold, italic or an entirely different font] as well as when using different font sizes.
Comment 1 Rainer Bielefeld Retired 2013-02-25 16:55:39 UTC
NOT reproducible with Server Installation of "LibO  4.0.0.3   -  GERMAN UI / German Locale  [Build ID: 7545bee9c2a0782548772a21bc84a9dcc583b89)]"  {tinderbox: @6, pull time 2013-01-31 11:30(?)} on German WIN7 Home Premium (64bit) with separate  new User Profile.

Reporter's sample looks fine, and also when I change color in second line of sample text still looks fine. I included 2 Screenshots into a new sample document

@Astron:
Operating System? Kerning settings for relevant letters before / after color change?
Other possibly relevant settings (anti aliasing, experimental features, ...)?
Comment 2 Rainer Bielefeld Retired 2013-02-25 17:11:43 UTC
Created attachment 75515 [details]
Sanple Document with WIN screenshots
Comment 3 Stefan Knorr (astron) 2013-02-25 21:31:01 UTC
Created attachment 75532 [details]
Screenshot OpenSUSE 12.2

Sorry, I should have mentioned the operating system etc.: OpenSUSE 12.2, x86-64, with freetype-infinality.

I noticed that the same bug exists in my AbiWord installation and Rainer's screenshot looks indeed fine. Maybe this bug is not directly in LibreOffice.
Comment 4 Stefan Knorr (astron) 2013-02-25 21:40:18 UTC
I can reproduce this in my Calligra installation (OpenSUSE 12.2, again), too. However, it also happens in LibreOffice 3.6 under Ubuntu 12.04.

...

It does not however appear in my AOO Windows Nightly installation under Wine/Linux.
Comment 5 Joel Madero 2013-02-26 03:39:58 UTC
Version 4.1.0.0.alpha0+ (Build ID: b8e0455f201198b1deb8f8ca0181e6c9cadc335)
Date:   Sat Feb 23 22:55:15 2013 +0100
Bodhi Linux 2.2

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Confirmed

New
Normal (prevents high quality work under some circumstances)
Medium (default, IMO no need to change)
Comment 6 Joel Madero 2013-02-26 03:43:33 UTC
Changing version - was an issue in version 3.6.0alpha0+ (Build ID: 099198) again on Bodhi Linux (first build with bibisect package)
Comment 7 Rainer Bielefeld Retired 2013-02-26 05:36:51 UTC
I wonder whether this is NOTOURBUG, but something deep in the Linux guts?

@Astron / Joel:
Die your tests have the result that with versions before 3.6 that was ok, or did you only not find the time to do a test with older versions?

Something I see, no idea whether it's important: The cursor position getween black "A" and Black "V" differs between Astron's screenshot and my one. Under WIN kerning cuts a little from the "A", under Linux it cuts a little from the "V".
Comment 8 Joel Madero 2013-02-26 06:17:14 UTC
I didn't go before 3.6 as I just use bibisect to go as far back as I can - I think it could be a quite complex fix but....it does look better when the kerning is working :-/
Comment 9 Stefan Knorr (astron) 2013-02-26 08:18:37 UTC
@Rainer, comment 7: I wonder the same now that I reproduced it about everywhere I could. Can we just CC a knowledgeable developer to tell us whether this is likely in Harfbuzz/Pango/Cairo/Freetype or anything else?
Comment 10 Rainer Bielefeld Retired 2013-02-26 08:32:25 UTC
@Astron (In reply to comment #9):
I also thought about asking a developer, but did not know whom.
Comment 11 Stefan Knorr (astron) 2013-02-28 15:41:16 UTC
Adding Caolan in the hope that he can help out. Caolan, who should we speak to about this?
Comment 12 Caolán McNamara 2013-02-28 21:05:06 UTC
I imagine that this has always been like that, and it'll be because the text is split into different "portions" because the properties are different and each run sent to vcl and down eventually into icu (or whatever) as two different blocks.

Raw debugging starting point would be a breakpoint in IcuLayoutEngine::layout vcl/generic/glyphs/gcach_layout.cxx and dig back up the backtrace to find the code that's splitting the text up according to different properties and see if there's any way to avoid the split due to just color, while still being able to render each resulting half with a different color persumably as a different writer "portion"

It *might* just work that if the runs differ only by color that adding in the preceeding/following chars as extra context to the ones we want the positions of might work, depending on what the intermediate layers do.

e.g. theory might be
REDBLUE
right now, ask for positions of "RED" in one portion and then for "BLUE" in another
future, one portion asks for "REDB" and only use positioning results for RED, then other portion asks for "DBLUE" and only use the results for BLUE.
Comment 13 Khaled Hosny 2013-05-02 05:49:15 UTC
(In reply to comment #12)
> I imagine that this has always been like that, and it'll be because the text
> is split into different "portions" because the properties are different and
> each run sent to vcl and down eventually into icu (or whatever) as two
> different blocks.

That is indeed the case, changing color causes the text to be laid out in different runs. Even worse, changing any font property has the same effect and often the changes are not visible to the user (like when changing the font and reverting it back). Basically anything that results in a different <span> in the saved ODT file will be laid out separately.

This can result in worse effects than just kerning, complex text layout can get completely broken, for example.

> It *might* just work that if the runs differ only by color that adding in
> the preceeding/following chars as extra context to the ones we want the
> positions of might work, depending on what the intermediate layers do.

This doesn’t work (I already does that when using HarfBuzz, and while this helps a bit with Arabic shaping, the engine will only apply OpenType features to the portion of text it is asked to shape).
Comment 14 QA Administrators 2015-04-19 03:22:36 UTC Comment hidden (obsolete)
Comment 15 Khaled Hosny 2015-04-19 19:53:17 UTC
This is still present, and without major restructuring of the way colour information is passed around internally, it is not going to magically solve itself.
Comment 16 QA Administrators 2016-09-20 09:33:04 UTC Comment hidden (obsolete)
Comment 17 Khaled Hosny 2016-09-21 07:40:39 UTC
Still an issue, unlikely to be fixed without some major rearchitecturing of how we do text styling.
Comment 18 Buovjaga 2017-04-27 18:44:47 UTC
*** Bug 107155 has been marked as a duplicate of this bug. ***
Comment 19 Khaled Hosny 2018-06-18 19:00:00 UTC
*** Bug 117535 has been marked as a duplicate of this bug. ***
Comment 20 F. Tremmel 2018-06-18 19:49:47 UTC
Still Confirmed for
Libreoffice 6.0.4.2 (x64) at Windows7

Libreoffice  6.04.2 (x64) at Linux (Chakra GNU/LInux)

Compare bug https://bugs.documentfoundation.org/show_bug.cgi?id=117535
Comment 21 F. Tremmel 2019-02-27 20:57:11 UTC
Still Confirmed for

Libreoffice  6.2.3 (x64) at Linux (Chakra GNU/LInux)

Compare bug https://bugs.documentfoundation.org/show_bug.cgi?id=117535
Comment 22 Khaled Hosny 2019-03-27 17:43:11 UTC
*** Bug 111631 has been marked as a duplicate of this bug. ***
Comment 23 Khaled Hosny 2019-03-27 17:46:18 UTC
*** Bug 124347 has been marked as a duplicate of this bug. ***