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, ...)?

Created attachment 75515 [details]
Sanple Document with WIN screenshots

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.

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.

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)

Changing version - was an issue in version 3.6.0alpha0+ (Build ID: 099198) again on Bodhi Linux (first build with bibisect package)

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".

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 :-/

@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?

@Astron (In reply to comment #9):
I also thought about asking a developer, but did not know whom.

Adding Caolan in the hope that he can help out. Caolan, who should we speak to about this?

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.

(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).

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.

Still an issue, unlikely to be fixed without some major rearchitecturing of how we do text styling.

*** Bug 107155 has been marked as a duplicate of this bug. ***

*** Bug 117535 has been marked as a duplicate of this bug. ***

Still Confirmed for

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

Compare bug https://bugs.documentfoundation.org/show_bug.cgi?id=117535

*** Bug 111631 has been marked as a duplicate of this bug. ***

*** Bug 124347 has been marked as a duplicate of this bug. ***

This issue is still present in

Version: 6.4.5.2
Build ID: 40(Build:2)
CPU threads: 4; OS: Linux 5.3; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

(as compiled by the openSUSE project in Leap 15.2.)

Created attachment 181790 [details]
Example file

I find it even easier to reproduce dancing glyps by applying highlighting to 1 or 2 Hebrew glyphs. It's not limited to alignment justified either :-(

once things are broken into different runs there's going to be such effects, its also probable that attempting to fix it might add some additional degree of incompatibility with msword

(In reply to Caolán McNamara from comment #27)
> its also probable that attempting to fix it might add some additional degree
> of incompatibility with msword

Last I checked (but it was a while ago), MS Word didn’t break runs for text color and underline (and possibly other formatting, but these are the two I remember testing).

Created attachment 181791 [details]
well well, indeed

Indeed, so it seems (with an ancient word 2003 anyway), so that's interesting. So moves in that direction would be towards compatibility which is neat. I had toyed in https://gerrit.libreoffice.org/c/core/+/128573 with laying out the entire string of a paragraph (though it probably won't work in the real world) to play around with some approach like that but abandoned it as out of scope at the time.

*** Bug 150724 has been marked as a duplicate of this bug. ***

*** Bug 149022 has been marked as a duplicate of this bug. ***

(In reply to Eyal Rozenberg from comment #32)
> I think this merits a severity upgrade, especially considering the number of
> duplicates. Stefan/Caolan/Telesto - would you mind? I don't have the
> permissions apparently.

Changing the importance/Severity has mostly no effect on this type of bug in my experience. It needs someone who is capable and having a desire & time to look into this. And well 6 duplicates in 9 years, surely not a big count, IMHO

And the overall situation improved a lot since 7.4. 

A more persuasive argument being needed why the current state being a big problem, instead of 'glitch'; IMHO. The is issue less prominent with Latin (and aligning left). It might be way worse with Hebrew/Arabic (comment 26) where the default is: RTL justified (Is it?). I really don't know anything about Hebrew/Arabic languages... Nor the importance of spacing between glyphs. And I'm surely less sensible for wrong rendering.. Which makes it really hard to make an assessment

Is it that bad that Hebrew/Arabic users are less likely to work with LibreOffice, for example?  

Ps. Don't get me wrong, I surely like this bug fixed; however it's more an inconvenience to me at this point.

@Telesto:
As you have correctly guessed this is more serious for Arabic than to Latin. For Arabic, this bug breaks connecting lines between letters and this is a serious issue. If in LibO you would consider rendering the letter 'w' as 'vv' as a big problem rather than a glitch, then this is the same.

Not that I am pushing anyone and I completely understand the lack of resources issue but just to answer your question and put this in perspective. I originally filed bug #149022 which is now a duplicate of this.

(In reply to Munzir Taha from comment #34)
> For Arabic, this bug breaks connecting lines between letters and this is a
> serious issue. If in LibO you would consider rendering the letter 'w' as
> 'vv' as a big problem rather than a glitch, then this is the same.

In this case: let's increase priority and severity to attract some (additional) attention.. and lets see what happens..

-----
It might be something for the tenders proposal list for next year: https://wiki.documentfoundation.org/Development/Budget2022 

But I prefer someone with DEV expertise writing the proposal. I have no clue what needs to be done.. And I'm unable to asses where the hurdles are. Like influence of RTL, justified alignment, glyph rendering, zoom-level/scaling/screen DPI, and possible the influence of text portions. And there might be even subtile difference in glyph rendering/positioning between ODT and DOCX export of the same text.

-----
@Munzir Taha
Is it possible to add an example file illustrating the problem and a screenshot of the expected rendering from a different application for comparison. I'm unable to spot the issue straight away, being unfamiliar with Arabic

Created attachment 182654 [details]
letters are disconnected and changed form

Created attachment 182655 [details]
letters are disconnected and changed form screenshot

(In reply to Munzir Taha from comment #38)
> Sure. Attached is a simple document where the first line is correct. I just
> duplicated it and applied a color in the second line. It's clear that it's
> not a matter of spacing. Applying a color shouldn't draw a Mona Lisa out of
> the letters for any language ;)


This particular issue is bug 150726, if you switch off show formatting marks you will get much less broken result.

@خالد حسني
As usual, your fixes are outstanding. I will test as soon as there is a build available.

Yes, I am aware that less broken results show when formatting marks are hidden as in the original bug I filed. So, now remains the broken characters like LAM ALEF combinations and ligatures.

I am not sure whether breaking shaping should be the same bug as breaking kerning. Yes, broken Arabic ligature shaping is similar to kerning because the text is still correct though not suitable for professional work. However, breaking shaping is more serious and the text is incorrect and can be handled in a different way.

In Scribus e.g. the kerning doesn't break due to color changes. For Arabic, Scribus still doesn't know how to handle the coloring for single characters of combinations correctly so it changes the color of the whole ligature, which is not perfect but at least the shaping is intact.

(In reply to Munzir Taha from comment #40)
> @خالد حسني
> As usual, your fixes are outstanding. I will test as soon as there is a
> build available.
> 
> Yes, I am aware that less broken results show when formatting marks are
> hidden as in the original bug I filed. So, now remains the broken characters
> like LAM ALEF combinations and ligatures.
> 
> I am not sure whether breaking shaping should be the same bug as breaking
> kerning.zYes, broken Arabic ligature shaping is similar to kerning because
> the text is still correct though not suitable for professional work.
> However, breaking shaping is more serious and the text is incorrect and can
> be handled in a different way.


Kerning (glyph positioning in general) and shaping (glyph substitution in general) are done in the same step, there is no way to fix one but not the other, regardless which is more severe. The underlying issue is the same; when LibreOffice sees a formatting change it splits the text and processes each portion separately.

> In Scribus e.g. the kerning doesn't break due to color changes. For Arabic,
> Scribus still doesn't know how to handle the coloring for single characters
> of combinations correctly so it changes the color of the whole ligature,
> which is not perfect but at least the shaping is intact.

This is orthogonal to the issue here. There is no single answer for how to partially color a ligature, since it is a single glyph. Some applications will apply the color of the first component to the ligature (Chrome and I think MS Office do this), others will use a mask and color the part of the glyph up to where the cursor is inserted (Firefox is actually the only application I know that does this, and it is not without issues, see https://faultlore.com/blah/text-hates-you/#style-can-change-mid-ligature).

This issue is about the shaping part, once this is done (if it ever gets done, it is not a simple task), we can then decide how to partially color ligature glyphs).

*** Bug 135126 has been marked as a duplicate of this bug. ***

*** Bug 152068 has been marked as a duplicate of this bug. ***

*** Bug 152067 has been marked as a duplicate of this bug. ***

From bug 138919 comment 14, posted by: Miklos Vajna
I guess what could work is to render these highlights similar to annotated text ranges or the cursor selection, which is an overlay on top of already positioned text. Doing that correctly (not sure if e.g. PDF export handles such overlays) and without introducing performance problems (now you would need to produce those overlays as well) sounds tricky, though.

Once you have such an overlay, the exact geometry of it is just a detail.

Last, this is layout, so if you change it, you perhaps need a compat option to not break old documents?
[tag] [reply] [−]Comment 15Telesto 2022-01-17 11:01:2

*** Bug 138919 has been marked as a duplicate of this bug. ***

*** Bug 135127 has been marked as a duplicate of this bug. ***

*** Bug 134454 has been marked as a duplicate of this bug. ***

*** Bug 155915 has been marked as a duplicate of this bug. ***

The bug is still present:

Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 43967453e15e1d054972a7586cfef8f8e0866270
CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: fr-FR (fr_FR); UI: fr-FR
Calc: threaded

I've posted a candidate patch for this bug here:

https://gerrit.libreoffice.org/c/core/+/167016

This change only fixes the Writer kerning issue raised in the original report.

Several of the duplicates filed against this bug seem to actually be instances of bug 124116. This change doesn't fix bug 124116, but it will make fixing it easier as a separate change.

(In reply to Jonathan Clark from comment #56)
> I've posted a candidate patch for this bug here

Does it have any effect on bug 71956?

> Several of the duplicates filed against this bug seem to actually be
> instances of bug 124116.

If you remember which, can you change their dupe target them accordingly? If not, tell me and we (=probably I) will go over them.

(In reply to Eyal Rozenberg from comment #57)
> (In reply to Jonathan Clark from comment #56)
> > I've posted a candidate patch for this bug here
> 
> Does it have any effect on bug 71956?

The output is still incorrect. The diacritics may have moved in certain cases, though.

> 
> > Several of the duplicates filed against this bug seem to actually be
> > instances of bug 124116.
> 
> If you remember which, can you change their dupe target them accordingly? If
> not, tell me and we (=probably I) will go over them.

I believe that 134454, 117535, 149022, 150724, and 155915 are all duplicates of 124116.

It's a tough call, since several of those bugs involved users trying to do 71956. However, they discuss the layout issue the attempt causes, not glyph styling per se.