Description: Recent fixes on LODev 5.3 cause wrong glyph orientation for CJK Symbols and Punctuation characters when they are used in vertical Mongolian. Steps to Reproduce: 1. Open attachment 128631 [details] and take screenshot 2. Disable HarfBuzz (Tools -> Options -> Advanced: Expert Configuration search for "TextLayoutEngine") and restart 3. Take screenshot again Actual Results: With HarfBuzz: U+300A/300B are rotated when render with Oyun Qagan Tig, but with Mongolian Baiti they looks upright. Without HarfBuzz: U+300A/300B are rotated even if using different fonts. Expected Results: To fix it, CJK brackets (U+3008–300F, U+3014–301B) should get their vertical form via vert/vet2 feature, otherwise rotate the glyph by text layout engine. Reproducible: Always User Profile Reset: No Additional Info: Version: 5.3.0.0.alpha1+ Build ID: c03c77ef4f46b81cd000ea26c4ef154044322535 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; TinderBox: Win-x86@39, Branch:master, Time: 2016-11-17_00:29:08 Locale: zh-CN (zh_CN); Calc: group User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0
Created attachment 128799 [details] Test with HarfBuzz
Created attachment 128800 [details] Test without HarfBuzz
Created attachment 128801 [details] Test fonts
(In reply to General Kutuzov from comment #0) > To fix it, CJK brackets (U+3008–300F, U+3014–301B) should get their vertical > form via vert/vet2 feature, otherwise rotate the glyph by text layout engine. Several bracktes encoded in Halfwidth and Fullwidth Forms range (U+FF08–FF09, U+FF3B, U+FF3D, U+FF5B, U+FF5D, U+FF5F, U+FF61) should also use this presetation form.
I consider this a font bug; it does not provide a ‘vert’ feature, and even if vertical shaping fallback was implemented in HarfBuzz (https://github.com/behdad/harfbuzz/issues/355) it won’t help here since the vertical presentation forms are drawn upright in this font.
BTW, do you get the correct behaviour with Firefox or Chrome?
On a second thought, I think we can reasonably handle this.
Khaled Hosny committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0f3861e65d8e652dcc31cf9a2f2b5c1a0a73b86d tdf#103969: Do fallback glyph rotation It will be available in 5.3.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.
It have no effect to me. Version: 5.3.0.0.alpha1+ Build ID: 883024d657fb45c7da459017d2f936aac5644bfb CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-11-21_22:51:20 Locale: zh-CN (zh_CN); Calc: group
I can’t see the effect even if I get 5.3 beta1. Version: 5.3.0.0.beta1 Build ID: 690f553ecb3efd19143acbf01f3af4e289e94536 CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; Locale: zh-CN (zh_CN); Calc: group
(In reply to Volga from comment #10) > I can’t see the effect even if I get 5.3 beta1. > > Version: 5.3.0.0.beta1 > Build ID: 690f553ecb3efd19143acbf01f3af4e289e94536 > CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: > new; > Locale: zh-CN (zh_CN); Calc: group Can anyone else confirm this?
Hi Khaled, I reopen the issue because I also see upright brackets.
Created attachment 129017 [details] Screenshot 5.3.0.0beta1
(In reply to Mark Hung from comment #13) > Created attachment 129017 [details] > Screenshot 5.3.0.0beta1 Do you reproduce it also on Linux (using the same fonts)?
Set to Windows since I do not see this on Ubuntu 16.04. Version: 5.3.0.0.beta1 Build ID: 690f553ecb3efd19143acbf01f3af4e289e94536 CPU Threads: 1; OS Version: Linux 4.4; UI Render: default; VCL: gtk2; Layout Engine: new; Locale: en-US (en_US.UTF-8); Calc: group
This need to investigate what prevent the expected output on Windows.
(In reply to Volga from comment #16) > This need to investigate what prevent the expected output on Windows. Since mostly users use LibreOffice on Windows, we should pay more attentions to that, and find better solution as soon as possible.
(In reply to Volga from comment #16) > This need to investigate what prevent the expected output on Windows. It seems to me that our GDI handles failed to process some special text oritation specified by our text layout engine.
Is this still an issue?
Yes, I still unhappy with LO 5.3.1, I have to use the syntax Mongolian Baiti:vert=0 to avoid that. Version: 5.3.1.2 (x64) Build ID: e80a0e0fd1875e1696614d24c32df0f95f03deb2 CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; Locale: zh-CN (zh_CN); Calc: group But ahter I enabled OpenGL, the problem seems disappeared, but I suffered another problems as bug 104854 pointed out. Version: 5.3.1.2 (x64) Build ID: e80a0e0fd1875e1696614d24c32df0f95f03deb2 CPU Threads: 4; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; Locale: zh-CN (zh_CN); Calc: group
(In reply to Volga from comment #20) > Yes, I still unhappy with LO 5.3.1, I have to use the syntax Mongolian > Baiti:vert=0 to avoid that. > And with a 5.3.2.0+ or master TinderBox build with patch for bug 103831?
(In reply to V Stuart Foote from comment #21) > (In reply to Volga from comment #20) > > Yes, I still unhappy with LO 5.3.1, I have to use the syntax Mongolian > > Baiti:vert=0 to avoid that. > > > > And with a 5.3.2.0+ or master TinderBox build with patch for bug 103831? Yes, I tested LODev 5.3.2.0.0, and I gotthe same results. Version: 5.3.2.0.0+ Build ID: b16868ab2f7f3f0e09d68faba75d16fff1d851c1 CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; TinderBox: Win-x86@62-merge-TDF, Branch:libreoffice-5-3, Time: 2017-03-14_01:36:03 Locale: zh-CN (zh_CN); Calc: group
Do you get the correct results with Firefox or Chrome, if so can you attach a test HTML file?
(In reply to Khaled Hosny from comment #23) > Do you get the correct results with Firefox or Chrome, if so can you attach > a test HTML file? On Firefox and Chrome I get the opposite results. With Oyun Qagan Tig 《》 remain upright, with Mongolian Baiti they looks proper, since this font has vert feature for such characters. Tested with any page of the following wiki: https://incubator.wikimedia.org/wiki/Wp/mvf
Hi, Mongolian Baiti lacks of vmtx and vhea table, despite it has virt in GSUB. GDI failed to use vertical font (i.e. @ isn't prepend to the font name ) and doesn't render it properly. Force the orientation to be Rotated when vmtx and vhea isn't available might fix the problem.
OK, I think we need to break out such limitations.
Created attachment 132626 [details] Test case with Microsoft 'Phags-pa This problem also affect 'Phags-pa script, a script invented for the written languages within the Yuan Dynasty of China. Windows has a system font named Microsoft PhagsPa to render this text, this font has some brackets encoded in CJK Symbols and Punctuation block with vert feature, but they are wrongly rotated. For more information related to 'Phags-pa, see: https://en.wikipedia.org/wiki/%27Phags-pa_script
Created attachment 132627 [details] Test font You can get Microsoft PhagsPa from here when you need for test.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20171030
Fixed in bug 111967. Tested in LODev 6.0 beta1, Windows 10. Version: 6.0.0.0.beta1 (x64) Build ID：97471ab4eb4db4c487195658631696bb3238656c CPU 线程：4; 操作系统：Windows 10.0; UI 渲染：默认; Locale: zh-CN (zh_CN); Calc: group threaded
This is still reproduce with 版本：5.4.4.1 (x64) Build ID：da790616461e15a10c95a80eb8ef8ee7b726c114 CPU 线程：4; 操作系统：Windows 6.19; UI 渲染：默认; 区域语言：zh-CN (zh_CN); Calc: group But not reproduce with Version: 6.0.0.0.beta1 (x64) Build ID：97471ab4eb4db4c487195658631696bb3238656c CPU 线程：4; 操作系统：Windows 10.0; UI 渲染：默认; Locale: zh-CN (zh_CN); Calc: group threaded That's so weird, is there anyway to fix in 5.4 branch?