Description: Fullwidth Colon (U+FF1A) and Fullwidth Semicolon (U+FF1B) are not rotated 90 degreed clockwise with the following chinese fonts: * Droid Sans Fallback * WenQuanYi Micro Hei (文泉驛微米黑) * Noto Sans CJK TC Regular * AR PL UMing TW * AR PL UKai TW * TW-Sung (全字庫正宋體) * TW-Kai (全字庫正楷體) Please attachment. Quote Volga's comment (https://bugs.documentfoundation.org/show_bug.cgi?id=98879#c25) > According to Unicode data, U+FF1A/FF1B has Tr property, which means they are fallback to Rotated if they does not have proper feature for vertical layout in a font, but consider these characters are different from bracket characters, I suggest LibO should giving an exception. > See: http://www.unicode.org/reports/tr50/#data Steps to Reproduce: 1. Make sure you have the affected fonts installed. 2. Download and open the attached odt file. Actual Results: Fullwidth Colon (U+FF1A) and Fullwidth Semicolon (U+FF1B) are not rotated 90 degreed clockwise. Expected Results: They should be rotated 90 degreed clockwise. Reproducible: Always User Profile Reset: No Additional Info: =-=-=-= LINUX =-=-=-= Version: 5.4.0.0.alpha0+ Build ID: 08750abc64a7ad82cac96adeb7a0bcdce7ac704d CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-02-28_00:23:27 Locale: zh-TW (zh_TW.UTF-8); Calc: group OpenGL: disabled =-=-=-= WINDOWS =-=-=-= Version: 5.4.0.0.alpha0+ Build ID: 472f92421b1b15dc765714a7c657704812859868 CPU threads: 4; OS: Windows 6.19; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-03-02_00:18:28 Locale: zh-TW (zh_TW); Calc: group OpenGL: disabled User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/56.0.2924.76 Chrome/56.0.2924.76 Safari/537.36
Created attachment 131599 [details] sample: common punctuations
Created attachment 131600 [details] screenshot on both linux and windows I couldn't install Droid Sans Fallback on Windows, so I just set the background color to gray.
In short, Chinese users expect vertical orientation of full-width colon(0xff1a) and semi-colon(0xff1b) to be Tu ( upright if transform does not exist ) instead of Tr. However I don't know the context how the orientation is defined for these two characters in Tr50. ( i.e Are they used exclusively by CJK? Was that a mistake, or some others ( ex, Japanese, Korean, or users in other language ) actually expect it to be Tr? ) I'd further check if characters have been rendered following the font design when I'm available.
One further thing to consider is that when I test the document with Microsoft Office, it also follows font design. So you might get inconsistent result across text processors, which (in my opinion) is bad in terms of document interoperability if Unicode standard isn't updated.
Table 4 in TR#50 (http://unicode.org/reports/tr50/#table_4) shows that both U+FF1A and U+FF1B in vertical mode can be upright, rotated and upright shifted and it is not clear which should be the default and whether it is language-dependent or not. They are the only symbols in the table showing such behavior. It seems that both Firefox and Chrome simply treat Tr and Tu as synonyms to U and do nothing special for the former, but if we did that then brackets in the vertical mode will be broken for fonts that do not provide vertical variants (Firefox gets around this by mapping the brackets to the vertical presentation forms, not sure what Chrome is doing if anything at all).
I think we can try to add an exception for such punctuations to make them always upright.
Hi Naru, Would you please help us? What does Japanese expect fullwidth colon and semi-colon to be in vertical writing?
Mark, UTR No.50 has some samples for this that you can see, but I think they relys on means of typographic feature.
(In reply to Volga from comment #8) > Mark, > > UTR No.50 has some samples for this that you can see, but I think they relys > on means of typographic feature. I saw the report again and I found the sample looks messed up a bit, sorry.
For characters whose has Tr property, I think we can try to add an whitelist for brackets to make others stay upright.
(In reply to Volga from comment #10) > For characters whose has Tr property, I think we can try to add an whitelist > for brackets to make others stay upright. Hi Volga, We already know the expectation. I'm reaching out for other non-Chinese perspective.
Mark Hung committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cd6b70497180dbf0f3f78684e74702c993bbe449 tdf#106295 fix vertical orientation for fullwidth colon and semicolon. It will be available in 5.4.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.
Mark Hung committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=465da7d95e17367e615ec5ef65f368d89c8d7f5d&h=libreoffice-5-3 tdf#106295 fix vertical orientation for fullwidth colon and semicolon. It will be available in 5.3.3. 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.