Created attachment 117537 [details] test document with some zero-width characters Steps to reproduce: 1. Input text with zero-width characters. 2. Expand spacing (Format → Character… → Position → Spacing). 3. Observe how zero-width characters cause additional spacing which they really shouldn’t (they’re supposed to be zero-width). I have tested this with today’s 4.4.5.2 and 5.0.0.4 builds on Windows (8.1), Mac (10.10.4) and Linux (Lubuntu 15.04). None of these get it right. As a rule, there is some additional spacing with Zero-Width (Non-)Joiner and with zero-width accents, whereas zero-width spaces behave OK (except on 5.0.0.4 on Mac OS X). However, the details differ from OS to OS. On Windows, which does not do any ligatures, the additional space is not where the Zero-Width (Non-)Joiner logically should be (according to input character sequence), but after the following character. On Mac and on Linux, which do ligatures, and on Windows zero-width accents, the additional space is where it logically should be. A strange behavior can be observed in the character dialog on Windows and on Mac: The preview of the selected word shows flawless spacing (without additional space), whereas in the actual document, the zero-width characters will cause additional spacing. Somehow, the preview of the dialog gets it right, but the document doesn’t. On Linux, the preview is equally wrong as the document. Other free applications that get the spacing right (without additional spacing) include Firefox or LaTeX. I am attaching a test document with some zero-width characters.
Created attachment 117542 [details] Test document display Test document display on 4.4.5.2 and 5.0.0.4 builds on Windows (8.1), Mac (10.10.4) and Linux (Lubuntu 15.04).
Created attachment 117568 [details] screenshot of document, print preview, and character preview I can reproduce. The screenshot shows, top to bottom, document, print preview, and character preview. Windows Vista 64 Version: 4.4.5.2 Build ID: a22f674fd25a3b6f45bdebf25400ed2adff0ff99
** 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
Created attachment 129026 [details] Better test document: Continuing text flow shows increased spacing after the affected words This is an improved test document. The test words are repeated. The continuing text flow shows how some words get the wrong increased spacing after the word.
Created attachment 129027 [details] Test document on Ubuntu Linux (LibreOfficeDev 5.3.0.0.beta1) This is how the test document displays on Ubuntu Linux 16.10, using the latest Beta LibreOfficeDev_5.3.0.0.beta1_Linux_x86-64. The font used in the examples is Linux Libertine 5.3.0 (LinLibertineTTF_5.3.0_2012_07_02.tgz). The characters fall into three groups: 1. Zero-width non-joiner and Zero-width non-break space and the combining breve below cause additional space at the character's position. 2. Zero-width joiner and Combining acute accent cause additional space AFTER the word. 3. Zero-width space and Word joiner display just fine. I guess the difference between groups 1 and 2 is that the characters in group 2 trigger a built-in smartfont behaviour in the font, while the characters in group 1 don't.
Created attachment 129028 [details] Test document on MacOS (LibreOfficeDev 5.3.0.0.beta1) This is how the test document displays on MacOS 10.12.1, using the latest Beta LibreOfficeDev_5.3.0.0.beta1_MacOS_x86-64. The font used in the examples is Linux Libertine 5.3.0 (LinLibertineTTF_5.3.0_2012_07_02.tgz). The characters fall into three groups: 1. Zero-width non-joiner and Zero-width non-break space and the combining breve below cause additional space at the character's position. 2. Zero-width joiner and Combining acute accent cause additional space AFTER the word. 3. Zero-width space and Word joiner display just fine. I guess the difference between groups 1 and 2 is that the characters in group 2 trigger a built-in smartfont behaviour in the font, while the characters in group 1 don't.
Created attachment 129029 [details] Test document on Windows (LibreOfficeDev 5.3.0.0.beta1) This is how the test document displays on Windows 10.0.1, using the latest Beta LibreOfficeDev_5.3.0.0.beta1_Win_x64. The font used in the examples is Linux Libertine 5.3.0 (LinLibertineTTF_5.3.0_2012_07_02.tgz). The characters fall into three groups: 1. Zero-width non-joiner and Zero-width non-break space and the combining breve below cause additional space at the character's position. 2. Zero-width joiner and Combining acute accent cause additional space AFTER the word. 3. Zero-width space and Word joiner display just fine. I guess the difference between groups 1 and 2 is that the characters in group 2 trigger a built-in smartfont behaviour in the font, while the characters in group 1 don't.
I have retested for the bug. The bug is still present on a currently supported version of LibreOffice (LibreOffice 5.2.2.3, MacOS 10.12.1). I have also tested LibreOffice 3.3.0. The bug is also present with 3.3, so I am setting the version to "inherited from OOo". The upcoming 5.3 release, while still suffering from the bug, brings an important change: Now the display is identically wrong accross different OS. I have added screenshots from LibreOfficeDev 5.3.0.0.beta1 on different OS (MacOS 10.12.1, Ubuntu 16.10, Windows 10.0.1).
** 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 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
I have retested for the bug. The bug is still present on a currently supported version of LibreOffice (LibreOffice 5.4.3.2, MacOS 10.13.2 or Ubuntu 17.10). I am adding another example file. It contains three increased spacing paragraphs with the nonsense word "llflll". The first two are supposed to look identical, but they do not: 1. The first paragraph has ligatures switched off by setting "liga=0" (using the font name "Linux Libertine:liga=0"). 2. The second paragraph has ligatures switched off by using the zero-width non-joiner (between the "f" and the "l"). It is supposed to look exactly like the first paragraph, but it does not. 3. The third paragraph uses the default "fl" ligature.
Created attachment 138481 [details] the paragraphs with "llflll"; first and second should look identical
Created attachment 138482 [details] Screenshot of the paragraphs with "llflll"; first and second do not look identical
Problem still exists in: Version: 6.2.2.2 Build ID: 2b840030fec2aae0fd2658d8d4f9548af4e3518d CPU threads: 4; OS: Mac OS X 10.14.4; UI render: default; VCL: osx; Locale: de-CH (en_CH.UTF-8); UI-Language: en-US Calc: threaded
Dear j_mach_wust, 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 https://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
Problem persists in: Version: 7.1.2.2 / LibreOffice Community Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4 CPU threads: 8; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: de-CH (en_CH.UTF-8); UI: en-US Calc: threaded
Dear j_mach_wust, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Created attachment 187188 [details] Document with LibreOffice 7.5.3 on macOS Current status: - Ligatures are disabled automatically when letter spacing is used (fixed in bug 66819). - Accents are no longer displaced and don’t cause double spacing. - All zero space characters don’t cause extra spacing except Zero width no break space (U+FEFF), I think this is the only remaining issue. This is testing with: Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 6; OS: Mac OS X 13.3.1; UI render: default; VCL: osx Locale: en-EG (en_EG.UTF-8); UI: en-US Calc: threaded
(In reply to خالد حسني from comment #18) > except Zero width no break space (U+FEFF), I think this is the only remaining issue. Checking more, it seems that the Unicode Text Segmentation algorithm (https://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries) treats U+FEFF as a single grapheme cluster i.e. a user-perceived character, so when letter-spacing we count it as one character and space it. This can be tested in https://util.unicode.org/UnicodeJsps/breaks.jsp, by copying the word deprecated from the document and choosing User Character from the drop down menu, and there will be two red lines where U+FEFF is. Given this and since the use of U+FEFF as zero width no break space is deprecated, I think there are no issues left here and this bug should be closed.
For the reporter: Please be free to reopen this bug if you can reproduce it with a newer version. LibreOffice 7.5 or LibreOffice 7.6