Bug 162934 - [EDITING] last (incomplete) line of fully-justified paragraph is itself fully justified if it ends in a space. Effect while typing new text is distracting reformat-flicker. Also probably just shouldn't, if *last* line of para.
Summary: [EDITING] last (incomplete) line of fully-justified paragraph is itself fully...
Status: RESOLVED DUPLICATE of bug 162220
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
24.8.1.2 release
Hardware: ARM macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-09-12 18:30 UTC by Rachel Greenham
Modified: 2024-09-16 22:28 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Screen recording of typing at end of a fully-justified paragraph (586.04 KB, video/mp4)
2024-09-12 18:30 UTC, Rachel Greenham
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rachel Greenham 2024-09-12 18:30:11 UTC
Created attachment 196408 [details]
Screen recording of typing at end of a fully-justified paragraph

When typing new text at the end of a paragraph that's set to be fully-justified (whether as an ad-hoc effect or part of the currently-selected style), once typing past the halfway or possibly two-thirds point across the line, that last line, incomplete, keeps trying to format itself to fill the line, as you type.

It's actually fully-justifying the last line if it ends with a space character. But the effect while typing new text is very distracting. It shouldn't be doing it on the *last* line of the paragraph.

Screen recording attached; it's easier to see than describe!

This was not the behaviour in the previous release version (24.8.0)

I haven't tested on other platforms, but it looks like it wouldn't be platform-specific.
Comment 1 steve 2024-09-13 09:44:13 UTC
Confirmed w Version: 24.8.1.2 (AARCH64) / LibreOffice Community
Build ID: 87fa9aec1a63e70835390b81c40bb8993f1d4ff6
CPU threads: 12; OS: macOS 14.6.1; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Comment 2 steve 2024-09-13 09:45:53 UTC
Unable to reproduce in Version: 25.2.0.0.alpha0+ (AARCH64) / LibreOffice Community
Build ID: bcadc9a6ec5be2541e259f0fa18022c0661c8df7
CPU threads: 12; OS: macOS 14.6.1; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded

so apparently already fixed in main.

@Rachel: can you confirm this works for you in main. https://dev-builds.libreoffice.org/daily/master/current.html
Comment 3 Xisco Faulí 2024-09-13 10:17:44 UTC
This issue got fixed by 22eac3145ca62d15b47d95f4df60ce38d4f5aa46. Unfortunately the fix is in LibreOffice 24.8.2...
Closing as duplicated of bug 162220

*** This bug has been marked as a duplicate of bug 162220 ***
Comment 4 Rachel Greenham 2024-09-13 11:54:30 UTC
Can confirm the bug is fixed in the 25.2 daily on macOS Sonoma. (It doesn't run on the macOS Sequoia beta of my previous tests due to possible off-topic notarisation issue)

I have confirmed the bug in 24.8.1.2 also exists on macOS Sonoma, and on Linux x64 in the appimage build - the flatpak build I usually use is still on 24.8.0.3 and does not show the bug - so my initial guess that it's not architecture-specific seems confirmed.

Cannot test the macOS 24.8.2 daily here as it only has an x64 build, no aarch64 (and I don't run Rosetta). So I await a bugfix release thereof ;-)
Comment 5 Xisco Faulí 2024-09-16 08:11:53 UTC
*** Bug 162977 has been marked as a duplicate of this bug. ***
Comment 6 László Németh 2024-09-16 22:28:01 UTC
(Note: Bug 162220 caused an other regression for the last paragraph lines, so only the fix for Bug 162725 fixed both regressions:

...
                // don't calculate with the terminating space,
                // otherwise it would result justified line mistakenly
                ( pPos->GetNextPortion() || !pPos->IsHolePortion() ) )
            {
...)