Created attachment 144915 [details] Native 2016 **without** compatibiliy mode When opening .doc files or .docx files that were created in pre-2007 versions, Word uses 'compatibility mode'. We appear to be using compatibility mode by default for documents that were created Word 2010+ without this option enabled. Steps to reproduce: 1. Open August12.docx in Word 2. Open in Writer 3. Note the line spacing layout issues
Created attachment 144916 [details] Word vs Writer. Note writer incorrectly imports the documents, taking up 2 pages instead of 1.
Created attachment 144917 [details] When compatibily mode is forced, Writer and Word are identical
Created attachment 144918 [details] [MS-DOC]: format correctly imported
Confirmed using LO 6.1.1.2 / Windows 7. To be precise, in Word the DOCX and DOC look different, and in Writer they look the same (and as the DOC in Word). The difference is that the paragraph that takes 4 lines in one case takes 5 lines in the other. When comparing the DOCX and DOC in Word, the difference comes from different character layout/spacing. In fact, it only occurs if the text is justified, not with other kinds of alignments.
Dear Luke, 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 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: 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
(In reply to Aron Budea from comment #4) >The difference is that the paragraph > that takes 4 lines in one case takes 5 lines in the other. There are two places where this happens (in Word 2016). The other is the line that starts with "Coffee Morning" which only takes one line in 2016, compared to 2 lines in old Word 2003. Confirmed that changing word/settings.xml compatibilityMode to 12 is all that is necessary to have Word 2016 treat it the same as Writer handles it. Like Aron says - nothing really special about these paragraphs... <w:pPr> <w:widowControl w:val="0"/> <w:jc w:val="both"/> <w:rPr> <w:rFonts w:eastAsia="MS Mincho"/> <w:sz w:val="20"/> <w:szCs w:val="20"/> <w:lang w:val="en-US"/> </w:rPr> </w:pPr>
(In reply to Luke from comment #0) > When opening .doc files or .docx files that were created in pre-2007 > versions, Word uses 'compatibility mode'. We appear to be using > compatibility mode by default for documents that were created Word 2010+ I don't think this statement is quite true. Word uses compatibility mode for any document that has an older version than it does. August12.docx has the setting compatibilityMode = 15. (native for Word 2013-2019) I changed that mode to 14 (native version of Word 2010) and then Word 2016 acted like LO. So this should be a change starting in Word 2013, and not starting in Word 2010 as implied. This really looks like a Microsoft bug to me. How can shifting to full justification reduce the amount of space needed for your text? But yeah, I tried typing a sentence in a new Word 2016 document. If it is only one or two characters spilling over to the next line, then full justification must be SHRINKING something and so the entire paragraph now fits on one line instead of two in non-justified mode.
Ahh, "intelligent spacing" is probably to blame here. See bug 71732, which would result in these kinds of "random" layouts. Perhaps nice on the eyes, but impossible for exact reproducibility. I'm tempted to mark this as a duplicate of that bug, but apparently Word has been doing this for longer than 2013. Google's instructions to turn on "justify like WordPerfect 6" only work for Word 2007 or Word 2010. So, it looks like in 2013 they have implemented their own algorithm and enabled it by default. https://answers.microsoft.com/en-us/office/forum/office_2013_release-word/wordperfect-justification-style-no-longer/d341fcca-c1b1-462b-a9a4-0c89a1489184
(In reply to Justin L from comment #8) > Ahh, "intelligent spacing" is probably to blame here. Oops. That should be bug 38159
*** Bug 124769 has been marked as a duplicate of this bug. ***
Lots of good information in bug 38159. Required reading.
sw/source/core/text/portxt.cxx lcl_AddSpace indicates that Asian text needs to justify very differently from Western. The "Format_" function is likely the place to hook in a smart-justify compatibility flag. The "CalcSpacing" and "GetSpaceCnt" functions calculate justified alignment. sw/source/core/text/guess.cxx and a few other places make it sound like fields might be a complicating factor.
*** Bug 130088 has been marked as a duplicate of this bug. ***
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7d08767b890e723cd502b1c61d250924f695eb98 tdf#130088 tdf#119908 smart justify: fix DOCX line count + compat opt. It will be available in 24.2.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.
Created attachment 190256 [details] simple test file
Created attachment 190257 [details] simple test file in MSO, LO 7.6 and LO 24 (fixing Bug 130088)
Created attachment 190260 [details] visual comparison of justification of Writer and MSO The picture shows, how the shrinking is implemented in MSO by using the available spaces (but the maximal shrinking is independent from the number of the spaces – at least in a line with enough spaces). Black text: MS Word, red text: LibreOffice Writer – the black text contains an extra character spacing after the text “3 Au” to give the same position after the last space).
Created attachment 190267 [details] screenshot Justin, this is how I see the test documents from description and from comment 15. August is not ok yet, but Lorem it is.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/17eaebee279772b6062ae3448012133897fc71bb tdf#119908 sw smart justify: fix justification by shrinking It will be available in 24.2.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.
Created attachment 190875 [details] Screenshot of shrinking lines of the simple test file Composite picture of Writer screenshots before (red) and after (black) implementing shrinking.
Áron, Bogdan, Justin, Luke: thanks for your feedback! Remaining problems (fix cursor positions in the shrunk lines, text portions, hyphenation etc.) will be filed in new issues.
"simple test file" from comment 15 is looking now as in Microsoft. Thanks, László Németh. Verified with Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 17eaebee279772b6062ae3448012133897fc71bb CPU threads: 16; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c1803de8a093739d189be54b2d9bd5634e9e79ee tdf#119908 sw smart justify: add unit test It will be available in 24.2.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.
*** Bug 134062 has been marked as a duplicate of this bug. ***
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/20cbe88ce5610fd8ee302e5780a4c0821ddb3db4 tdf#119908 tdf#158419 sw smart justify: fix cursor position It will be available in 24.2.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.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/7059a1858ddb044c5f3f0c8e0386d3e1d9dd2b5f tdf#119908 tdf#158439 sw smart justify: fix freezing with NBSP It will be available in 24.2.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.
László Németh committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/36bfc86e27fa03ee16f87819549ab126c5a68cac tdf#119908 tdf#158776 sw smart justify: shrink only spaces 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.
Created attachment 191521 [details] composite screenshots of before (black) and after (red)
László Németh committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/8d247e3ad47e0b828437abb019e1573dbb1c05b1 tdf#119908 tdf#158776 sw smart justify: shrink only spaces 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.
I think this feature will be a great improvement for LO. There has been great interest for better text justification in Writer for long time, see bug #38159. However, have I understood correctly that this feature will be enabled only for imported Word documents that use 'smart justify' feature. If so, I would ask you to consider bringing this feature to all Writer documents. Either as paragraph alignment justified sub option or as Tools->Options->LibreOffice Writer->Compatibility option.
I highly seconde devseppala's comment, I would really like to test the new text justification for typesetting, but I am not willing to convert all documents to docx for that. Since the option is available for odt converted from docx, is there a way to force it manually? Even if it requires fiddling with the xml manually inside the odt.
Opening the simple test file from comment 15 I still get "Aliquam velit massa... Donec" in the third paragraph (while with a spacing of -0.1pt the following "consequat" would fit on the line). Anything I have to enable first? Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 806362b915ee89a4f907905a8ac8c1527ea99223 CPU threads: 32; OS: Linux 6.7; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded