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.
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).
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT *Update the version field *Reply via email (please reply directly on the bug tracker) *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-18
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.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
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.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
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. ***
Dear Stefan Knorr (astron), To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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. ***
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.
(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
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 ;)
(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).
Thanks for the clarification Khalid. For the errors related to to the "Toggle Formatting Marks" which I've numbered 2 and 3, should these be fixed by the patch in bug #150726 ? I thought so and tested but they are not fixed there.
(In reply to Munzir Taha from comment #42) > Thanks for the clarification Khalid. > > For the errors related to to the "Toggle Formatting Marks" which I've > numbered 2 and 3, should these be fixed by the patch in bug #150726 ? I > thought so and tested but they are not fixed there. They should be fixed in the sense that toggle formatting marks will make no difference in the output, but the colored line still different from the one without color (which is what this issue is about).
Created attachment 182709 [details] letters are disconnected, and "Toggle Formatting Marks" still break text even after the patch to bug #150726
@خالد حسني > toggle formatting marks will make no difference in the output But it does make a difference. With toggle formatting off, I get error number 1 only, with toggle formatting on, I get errors numbered 1, 2 and 3. It's exactly like the screenshot I pasted before, but I will still attach a new one with the version I am using.
(In reply to Munzir Taha from comment #45) > @خالد حسني > > > toggle formatting marks will make no difference in the output > > But it does make a difference. With toggle formatting off, I get error > number 1 only, with toggle formatting on, I get errors numbered 1, 2 and 3. > It's exactly like the screenshot I pasted before, but I will still attach a > new one with the version I am using. Lets continue this on bug 150726, it is getting off-topic here.
*** 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.
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/30d376fb7ded4c96c85ad1112a0e44b5929657c9 tdf#61444 Correct Writer text layout across formatting changes It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.