Description: Mongolian letters sometimes does not join with NNBSP, especially when this space is not following Mongolian letters. Steps to Reproduce: 1. Open Writer 2. Insert -> Frame -> Frame Interactively 3. Set text direction as Left-to-Right (vertical) 4. Copy the text from https://incubator.wikimedia.org/wiki/Wp/mvf/%E1%A0%AD%E1%A0%A6%E1%A0%B6%E1%A0%A6%E1%A0%AD_%E1%A0%AC%E1%A0%A0%E1%A0%AD%E1%A0%A0%E1%A0%A8_%E1%A0%A4_%E1%A0%AA%E1%A0%A2%E1%A0%B4%E1%A0%A2%E1%A0%AD%E1%A0%8C 5. Select all texts, set western font as Liberation Serif, set complex font as Mongolian Baiti. 6. Copy & paste the frame 7. Select all texts at the next frame, set font as Mongolian Baiti. Actual Results: Mongolian letters failed to join with NNBSP if NNBSP followed by digits. See my screenshot. Expected Results: Mongolian letters should always join with NNBSP. Reproducible: Always User Profile Reset: No Additional Info: 版本：5.4.2.1 (x64) Build ID：dfa67a98bede79c671438308dc9036d50465d2cb CPU 线程：4; 操作系统：Windows 6.19; UI 渲染：默认; 区域语言：zh-CN (zh_CN); Calc: group User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Created attachment 136491 [details] Test file
Created attachment 136492 [details] Rendering on LibreOffice
Created attachment 136493 [details] Original text rendering on Firefox
Created attachment 136494 [details] Original text rendering on Chrome
So the problem is before the string [ 1246 ?
(In reply to Buovjaga from comment #5) > So the problem is before the string [ 1246 ? No, it’s after the string 1246.
Ok, confirmed. Arch Linux 64-bit, KDE Plasma 5 Version: 6.0.0.0.alpha1+ Build ID: 7a2e7c32d38db02aaa5d78d5e8aaf86cabfde586 CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; Locale: fi-FI (fi_FI.UTF-8); Calc: group Built on October 28th 2017
Is there anyway to make MMBSP works the same as ZWJ while
Is there anyway to make NNBSP works the same as ZWJ?
Still reproduce in Version: 6.0.0.1 (x64) Build ID：d2bec56d7865f05a1003dc88449f2b0fdd85309a CPU 线程：4; 操作系统：Windows 10.0; UI 渲染：默认; 区域语言：zh-CN (zh_CN); Calc: group As a workaround, inserting ZWJ between space and Mongolian letter would works. This can be done in the following steps: 1. Type “200D” between them 2. Select the code 3. Press Alt + X This method could making Mongolian suffixes works as expected in this case, but couls making them breakable, further more, so many Mongolian fonts having contextual forms after NNBSP, so there is necessary to improve LibO to make Hudum Mongolian text well performanced.
** 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
Volga: and how about this one? Is it still reproducible?
Created attachment 167618 [details] Rendering on LibreOffice 7.0.3 Yes, I can still reproduce.
Dear Volga, 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
Here is a simpler test string: [ 1246 ᠣᠨ ᠤ 11ᠰᠠᠷᠠᠠ ᠢᠨ 3 ᠤ ᠡᠳᠤᠷ ᠡᠴᠡ11 ᠤ ᠡᠳᠤᠷ ] It does not have to be set vertically either. The character after the 3 and the second 11 should look like the one before the first 11. It seems to be a text segmentation issue; we classify the number as Western text and the NNBSP after them seems to be classified with them as well.
(In reply to Volga from comment #9) > Is there anyway to make NNBSP works the same as ZWJ? I got fooled by this visible difference for the better part of the day, but actually we are treating NNBSP and ZWJ the same here, they are always grouped with the previous character when we itemize scripts, so they are part of the Western text here. The difference is that HarfBuzz handles ZWJ itself and it is cleaver enough to still handle it even when asked to shape only the part of the text string after ZWJ. The NNBSP, on the other hand seems to be handled by the font itself (using glyph substitutions), so when we ask for shaping only the part of the text string after NNBSP, font substitutions don’t get applied.
Khaled Hosny committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d6efe8c302b81886706e18640148c51cf7883bbf tdf#112594: Group NNBSP with the Mongolian characters after it 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.
Is it possible to backport to 7.6 release channel?
Khaled Hosny committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/a319e879d80182d32de1f0b2aab9d581904e58aa tdf#112594: Group NNBSP with the Mongolian characters after it It will be available in 7.6.1. 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.