japanese Kanas don't use consistent fonts after special characters in language neutral content
Reported by
human.p...@gmail.com,
Jul 18 2016
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.8 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Open chrome://settings/languages to make sure you only have English enabled. At least, don't have any Japanese or Chinese languages (or variants) in that list which will affect the result. Also make sure you never modify font settings, which can be ensured by suing a new person. 2. Open the text file attached. 3. Check the "あ" in every lines (I copied below, should have the same effect). 『あああ』 【あああ】 あああ What is the expected behavior? The "あ" should be in the same font. What went wrong? They're not. To be more precise, the first "あ" and "『" or "【" are in Chinese font, SimSun, while the other "あ" and following "』" or "】" are in Japanese default font, Meiryo (the actual font may vary depends on your system. But the point stands). Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? N/A Does this work in other browsers? Yes Chrome version: 53.0.2785.8 Channel: dev OS Version: 10.0 Flash Version: Shockwave Flash 22.0 r0 I understand when no language is explicitly indicated (either by user's setting of language preference or html attribute, or encoding of webpage), Chromium has to guess one based on the characters themselves. For example, the "将" will always be shown in Chinese font (the glyph is slightly different from Japanese one, so it's easier to tell) if no language preference is assigned, instead of Japanese font. This is totally understandable. However, for Kanas because they should always be displayed in Japanese font, since they're exclusively used in Japanese (despite most of Chinese fonts would include these glyphs). It is MOSTLY the case in Chromium; however, when they're following some symbols, like "『" and "【" I mentioned above (by the way, these two kinds of brackets are used in both Japanese and Chinese; and it's more prevalent in Japanese), they (the bracket mark and the kana) will weirdly become Chinese font. I vaguely remembered there was no such issue before, so it would be a regression. But I am not very sure about this.
,
Jul 19 2016
,
Jul 20 2016
,
Jan 27 2017
I wrote a test page for similar situation, that is, if a line begins with Left Corner Bracket 「, the next kana character will be rendered with either SimSun or PMingLiu depending on the version of Chrome browser. However, if there is other leading kana character before the Left Corner Bracket 「, it will displayed whole line in Meiryo. 「てすとです」 てすと「てすとです」 UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36 Example URL: https://pste.eu/p/cqZw.html Steps to reproduce the problem: 1. Ensure the Windows display language is set other than Japanese, preferably Chinese 2. Visit the web site above 3. Press F12 and inspect the font used to render the text What is the expected behavior? All kana characters should be rendered with the same font. Preferably the brackets should also be rendered with same font. What went wrong? On version 49.0.2618.8 and above, the "「て" in the first line is rendered with SimSun or PMingLiU. On version 49.0.2587.3, the whole first line was rendered with SimSung, and the second line was rendered with Meiryo On version 48.0.2564.22 and before, only the brackets are rendered in SimSung and kana characters are rendered in Meiryo. Does it occur on multiple sites: Yes Is it a problem with a plugin? No Did this work before? Kind of. On version 48.0.2564.22 and before, at least all of the kana characters were rendered with Meiryo Does this work in other browsers? Yes
,
Jan 27 2017
Thank you for confirmation of the bug and the regression window. I'm glad there are other people find this annoying :D
,
Mar 9 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Mar 12 2018
I can't reproduce this anymore, I suspect it may have been fixed with issue 758380 and commit 83821ae6fdc08f0ed0dbca13ad20d90fca7f3050 which was released in M63. Marking as WontFix/AlreadyFixed, please reopen if you still see this issue occurring.
,
Mar 12 2018
I indeed cannot reproduce this anymore either. Thanks for your time. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by dtapu...@chromium.org
, Jul 19 2016