Bug 159050 - FORMATTING Format error in paragraphs formatted with justified text
Summary: FORMATTING Format error in paragraphs formatted with justified text
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
24.8.0.0 alpha0+
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:24.8.0 target:24.2.0.2
Keywords: regression
Depends on:
Blocks:
 
Reported: 2024-01-06 20:14 UTC by Stefan_Lange_KA@T-Online.de
Modified: 2024-01-20 21:14 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
zip file with test documents, screenshots and pdf created from the test documents (10.17 MB, application/x-zip-compressed)
2024-01-06 20:14 UTC, Stefan_Lange_KA@T-Online.de
Details
Minimal reproducer (2.33 KB, application/vnd.oasis.opendocument.text)
2024-01-11 03:57 UTC, Mike Kaganski
Details
Test document produces the error despite LO build with the fix was used (426.29 KB, application/vnd.oasis.opendocument.text)
2024-01-14 23:08 UTC, Stefan_Lange_KA@T-Online.de
Details
Minimized sample for comment 15 (14.68 KB, application/vnd.oasis.opendocument.text)
2024-01-15 04:43 UTC, Mike Kaganski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan_Lange_KA@T-Online.de 2024-01-06 20:14:02 UTC
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
Comment 1 Stefan_Lange_KA@T-Online.de 2024-01-06 21:56:11 UTC
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.
Comment 2 Stefan_Lange_KA@T-Online.de 2024-01-10 15:21:48 UTC
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
Comment 3 Stefan_Lange_KA@T-Online.de 2024-01-10 18:26:11 UTC
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
Comment 4 Stefan_Lange_KA@T-Online.de 2024-01-10 18:57:57 UTC
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.
Comment 5 Stefan_Lange_KA@T-Online.de 2024-01-10 22:52:01 UTC
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.
Comment 6 Mike Kaganski 2024-01-11 03:25:09 UTC Comment hidden (obsolete)
Comment 7 Mike Kaganski 2024-01-11 03:26:48 UTC Comment hidden (obsolete)
Comment 8 Mike Kaganski 2024-01-11 03:57:57 UTC
Created attachment 191862 [details]
Minimal reproducer
Comment 9 Mike Kaganski 2024-01-11 06:54:40 UTC
(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.
Comment 10 Stefan_Lange_KA@T-Online.de 2024-01-11 07:04:19 UTC
(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!
Comment 11 Mike Kaganski 2024-01-11 07:21:20 UTC
https://gerrit.libreoffice.org/c/core/+/161910
Comment 12 Commit Notification 2024-01-11 08:14:24 UTC
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.
Comment 13 Commit Notification 2024-01-11 12:16:06 UTC
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.
Comment 14 Stefan_Lange_KA@T-Online.de 2024-01-12 10:01:55 UTC
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.
Comment 15 Stefan_Lange_KA@T-Online.de 2024-01-14 23:08:17 UTC
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.
Comment 16 Mike Kaganski 2024-01-15 04:43:57 UTC
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...
Comment 17 Stefan_Lange_KA@T-Online.de 2024-01-15 21:31:47 UTC
(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.
Comment 18 Stefan_Lange_KA@T-Online.de 2024-01-20 21:14:20 UTC
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.