Created attachment 191790 [details] zip file with test documents, screenshots and pdf created from the test documents In some cases lines of a paragraph formatted with justified text are formatted incorrectly when the line is bordered at the right by an image with wraparound: The text is formatted not with the normal character spacing, but with a greater. As result the end of the line is covered by the image. As seen in the test document much text parts are formatted correctly but some text parts are always incorrectly formatted. I don't know the reason or the specific circumstances what lines are formatted incorrectly. When the paragraph is formatted with left alignment the problem doesn't exist. Reproducing the problem: - open the document "Alte Fotoapparate V6.4.2_LO_24.8_Fehler_klein_V2_markiert.odt" from the attached zip document (or "Alte Fotoapparate V6.4.2_LO_24.8_Fehler_klein_V2.odt" - same content, but incorrectly formatted text parts not coloured) with a LOdev 24.8 build created on 2024-01-01 or later. - look at the lines coloured with "Light brick 3" in the paragraphs from 1.1.1.2 on: they are formatted with greater letter spacing. - Exception: In paragraph 1.1.1.1 I have formatted the coloured text part left aligned and the text is displayed correctly. The problem doesn't exist in LO(dev) 24.2 and in LOdev 24.8 builds created before 2024-01-01. First build with the bug: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c899d3608d30f3ab4c2bc193c1fcd765221614a4 CPU threads: 4; OS: Windows 10.0 Build 22635; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded Link to the commits: https://git.libreoffice.org/core/+log/c899d3608d30f3ab4c2bc193c1fcd765221614a4 Changes belonging to: starting at c899d36 ... by László Németh until 3653efd ... by Noel Grandin
I have tried to bibisect the bug but it seems the "latest" data in the newest repository (Win64-24.2) are 5 weeks old and there are no data for LO 24.8.
The bug was transferred also to 24.2.0.1.0+. With Version: 24.2.0.1.0+ (X86_64) / LibreOffice Community Build ID: 958089803917f46c81ca818b791c846c072f6fca CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded from 2024-01-06 the behavior was still OK, but with Version: 24.2.0.1.0+ (X86_64) / LibreOffice Community Build ID: 3e6fa4da057be191aac0973e5131d271de0d5e61 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded from 2024-01-10 the bug seen until now only in 24.8 is arrived in 24.2. I have reproduced the behavior with my test document "Alte Fotoapparate V6.4.2_LO_24.8_Fehler_klein_V2_markiert.odt". Link to Commits: https://git.libreoffice.org/core/+log/3e6fa4da057be191aac0973e5131d271de0d5e61 I know it doesn't replace a bibisect but because the bug cannot be bibisected until now (data to old) I have looked in the lists of changes for names (not numbers) occuring in both lists - from 3e6fa4da057be191aac0973e5131d271de0d5e61 and from c899d3608d30f3ab4c2bc193c1fcd765221614a4. I have found only three changes ocuring in both lists: adfbec2 / 7609423 No need to decrement the position for Hole portion case a097d6e / 853e13f tdf#57187: make sure to put trailing blanks to hole portion in narrow lines fd1f76d / 46b0666 tdf#158254: don't shrink to data area when applying to entire sheet
Because the bug before the end of 2023 didn't exist and first occured in builds created in 2024 I have signed it as "Regression". I would also change earliest affected version but 24.2.0.0 beta1+ is not correct and 24.2.0.1.0+ is not in the list. Addition: 24.2.0.1 rc1 is not affected yet by the bug. Version: 24.2.0.1 (X86_64) / LibreOffice Community Build ID: b4d45829793cddfe67b58a53f495528c75738d8a CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded
I have looket at a097d6e tdf#57187: make sure to put trailing blanks to hole portion in narrow lines by Mike Kaganski Because it fixes the bug tdf#57187 (His topic is also the handling of justified text.) I can imagine there is a relation to my reported bug.
To test if there is a relation of the change to fix tdf#57187 to my bug I have tested with my test document "Alte Fotoapparate V6.4.2_LO_24.8_Fehler_klein_V2_markiert.odt": I have replaced the space at the end of a wrongly formatted line by Shift + Enter (topic of tdf#57187, line break within a paragraph) and - oops - as result the line is formatted correctly! I think this is almost a sure indication that there is a relation! But this (a line break instaed of space) is not a solution for me and also not a workaround, because the line break remains when I remove the picture that causes the line wrap or change its position.
Opening "Alte Fotoapparate V6.4.2_LO_24.8_Fehler_klein_V2_markiert.odt" with Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7bd7085bcfce0b32179197a14189604d4c7478e1 CPU threads: 24; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded I see the first marked region (in 1.1.1.1) shown exactly as in 7.6.4.1; while the second marked area (in 1.1.1.2) shows wrong still. I believe that the changed factor in the range between c899d3608d30f3ab4c2bc193c1fcd765221614a4 and 7bd7085bcfce0b32179197a14189604d4c7478e1 was this commit from László: d511367c102ef2ada0f73dbe81744d39865d58ba
(In reply to Stefan_Lange_KA@T-Online.de from comment #0) > - Exception: In paragraph 1.1.1.1 I have formatted the coloured text part > left aligned and the text is displayed correctly. Ah - I missed this. Sorry.
Created attachment 191862 [details] Minimal reproducer
(In reply to Stefan_Lange_KA@T-Online.de from comment #4) > I have looket at > a097d6e ... You are absolutely correct. One nit if I may. Please don't post shortened hashes; post them in full. This makes them nicely linkified - like in a097d6e85308f1f9dc91746e98faf46767a1531b ; and makes it easier to navigate. Thank you.
(In reply to Mike Kaganski from comment #9) > (In reply to Stefan_Lange_KA@T-Online.de from comment #4) > > I have looket at > > a097d6e ... > > You are absolutely correct. > One nit if I may. Please don't post shortened hashes; post them in full. > This makes them nicely linkified - like in > a097d6e85308f1f9dc91746e98faf46767a1531b ; and makes it easier to navigate. > Thank you. OK!
https://gerrit.libreoffice.org/c/core/+/161910
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6dbe164d730726b0a91fdef70ba16410f9d81dc4 tdf#159050: let fly portion swallow hole portion width 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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/3ab08b58cbac8be8bbd5d5a409b54e488b0e2c73 tdf#159050: let fly portion swallow hole portion width It will be available in 24.2.0.2. 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.
Test with Version: 24.2.1.0.0+ (X86_64) / LibreOffice Community Build ID: 7a0513ce48ed6da73eec22ba20ea8a7dcce8ec1d CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded was succesful: The text is correctly formatted again (as before the bug was implemented ☺)! I have tested with the minimal reproducer document, with my own attached test documents and with my big orignal document where I have seen the bug first. Mike, many thanks for very fast fixing the problem! The test with 24.8 is still open. I will run it as soon as a new build is available.
Created attachment 191933 [details] Test document produces the error despite LO build with the fix was used In a special constellation the bug occured with Version: 24.2.1.0.0+ (X86_64) / LibreOffice Community Build ID: 45023ae9619cdc4332afb8f743d1695a23e8d866 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded although this build contains the fix and the fix works properly in general. I edited my text and an invalid word was "created" (does not exist in the German language) and within this word occured different character styles (different colors, but same effect with different font styles). In the test document "tdf159050-wrap-adjust-problem-wrong-word-char-style-change.odt" this constalltion is reproduced in the first occurance of the text "keine Gebrauchsspurengarantie". In the other three occurances the text is formatted correctly (2: different color ended before the point of lineline break caused by hyphenation, 3: no different colors, 4: the word is "invalid", but written correctly). Because this (new) problem also occurs with Version: 24.2.0.1 (X86_64) / LibreOffice Community Build ID: b4d45829793cddfe67b58a53f495528c75738d8a CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded, that is not affected by Bug 159050, I am not sure if it would be better to open a new bug or to handle it here.
Created attachment 191941 [details] Minimized sample for comment 15 (In reply to Stefan_Lange_KA@T-Online.de from comment #15) > I am not sure if it would be better to open a new bug or to handle it here. Note that this is completely different. It was the same in e.g. 7.6.0, and even 5.0.0. In 3.3.0, it was also same - except it didn't join identical direct formatting on opening of ODT, so looked even worse. So it is not a regression, not related to my changes - so must definitely be filed separately...
(In reply to Mike Kaganski from comment #16) > Created attachment 191941 [details] > Minimized sample for comment 15 > > (In reply to Stefan_Lange_KA@T-Online.de from comment #15) > > I am not sure if it would be better to open a new bug or to handle it here. > > Note that this is completely different. It was the same in e.g. 7.6.0, and > even 5.0.0. In 3.3.0, it was also same - except it didn't join identical > direct formatting on opening of ODT, so looked even worse. So it is not a > regression, not related to my changes - so must definitely be filed > separately... I have expected this and it is OK! I have also found that since LO 4 the wrong behavior is the same as now and in LO 3.x (tested with 3.3 and 3.5) it was worse - means it is herited from OO. I will report a new bug but I think it is one with minor priority.
I have tested now also the LO 24.8 64bit version. With Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: ad0266eb84eafa32ccc4e0ddf3c6392860bc9b13 CPU threads: 4; OS: Windows 10.0 Build 22635; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded the bug is fixed too.