Created attachment 71902 [details] Demo document. Notes and screenshot included. I've found that line breaks aren't treated as nicely as regular paragraph breaks when it comes to hanging punctuation. I don't remember if it was an Asian text only option, but when hanging punctuation is on, if punctuation is the last character in a line it'll be squeezed in on that line, even if there normally wouldn't be enough space. Further, if hanging punctuation is then followed by a paragraph break, that paragraph break will also hang on to the end of the line. If, however, instead of a paragraph break a line break (far more common) follows the hanging punctuation, the line break gets pushed to the next line, resulting in an empty line following the hanging punctuation. This problem has been around for a while (at least since 3.6). Win7x64Ult.
Only the 'non-printable character' for 'new line'/'enter' is behind the margins of the document. It seems like I can't reproduce the 'point' falling of the document. I'll upload 2 screenshots. One of LibreOffice 3.6.4.3 (Dutch) and LibreOffice 4.1.0.0.alpha0+ (Build ID: b1a4afa3b45d7b256eaf5aa88497b092f0139c8) (No helppack installed). No regression (document in both version are identical).
Created attachment 71915 [details] Screenshot LibreOffice 3.6.4.3 under Ubuntu 12.10
Created attachment 71916 [details] Screenshot LibreOffice Version 4.1.0.0.alpha0+ under Ubuntu 12.10
I can reproduce How to reproduce: *Open demo document *Show non-printable characters *Select the first Japanese sentence (without the 'point') *Font size -> 38 Current behavior: that 'point', that you didn't resize, is falling the 'document' (behind right boundary). The paragraph break is behind that point, also falling of the document (not that big problem, but important later in this 'how to reproduce) Expected behavior: point don't fall of document, so the point is still at the second line. *Put your cursor at the beginning of the following (Japanese) sentence *Hit backspace (= delete paragraph character) *Shift+enter Current behavior: the paragraph character isn't replaced by a 'hard enter'(shift+enter) character. The hard enter create a gap between first and second sentence. This is a more appropriate behavior, because we're working NORMALLY on the second line. The point is still falling of document. Expected behavior: the 'hard enter' just replace the 'paragraph character' (='enter'). Same behavior as a paragraph character. NB: if you delete the paragraph character, and then hit 'enter' again, the paragraph character is also at the first line (=same as before we delete it). Ubuntu 12.10 LibreOffice 3.6.4.3 (Build-id: 360m1(Build:3)); Dutch UI;
Fr those unfamiliar with Japanese print: In Asian languages it is common to allow punctuation to hang off the end of a line beyond the normal text borders. In LibreOffice this is enabled by an option called 'Allow hanging punctuation' under the Asian Typography tab of the paragraph formatting dialog. This is normal behavior. The bug in this report is that line breaks do not hang off of (stay on the same line as) hanging punctuation like paragraph breaks do.
(In reply to comment #4) > I can reproduce > > How to reproduce: > *Open demo document > *Show non-printable characters > *Select the first Japanese sentence (without the 'point') > *Font size -> 38 > Ok, I didn't know that. Not that familiar with Japanase :). > Current behavior: that 'point', that you didn't resize, is falling of the > 'document' (behind right boundary). The paragraph break is behind that > point, also falling of the document (not that big problem, but important > later in this 'how to reproduce) NOT A BUG: > Expected behavior: point don't fall of document, so the point is still at > the second line. A BUG: > *Put your cursor at the beginning of the following (Japanese) sentence > *Hit backspace (= delete paragraph character) > *Shift+enter > > Current behavior: the paragraph character isn't replaced by a 'hard > enter'(shift+enter) character. The hard enter create a gap between first and > second sentence. This is a more appropriate behavior, because we're working > NORMALLY on the second line. The point is still falling of document. > > Expected behavior: the 'hard enter' just replace the 'paragraph character' > (='enter'). Same behavior as a paragraph character. > > NB: if you delete the paragraph character, and then hit 'enter' again, the > paragraph character is also at the first line (=same as before we delete it). > > Ubuntu 12.10 > LibreOffice 3.6.4.3 (Build-id: 360m1(Build:3)); Dutch UI;
*** Bug 62545 has been marked as a duplicate of this bug. ***
** 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.0.0.5 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-09-03
** 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 broken as of 5.1; the test document (first attachment) still behaves as described within. If this were fixed, the second set of text should look (almost) exactly like the first.
Mark Hung committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=89f038765a36a938961863efea2e0e07515f44d6 tdf#58604 keep line break follows hanging punctuation. It will be available in 5.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Nope, no apparent change in behavior. The line break is still getting pushed to the next line.
Oop I was using the wrong version; it looks fixed as of the latest dailies (libo-master64~2017-06-14_00.16.05_LibreOfficeDev_6.0.0.0.alpha0_Win_x64)
This is your bug. If you say it's fixed, just mark as such. I did it now.