| Issue 3031: | Accented Thai characters display issue in Thai web pages | |
| 6 people starred this issue and may be notified of changes. | Back to list |
Sign in to add a comment
|
Google Chrome OS 0.7.40.6 (Official Build d3b9690f) Google Chrome 5.0.382.3 (Official Build 45472) WebKit 533.6 Type of computer : Eeepc 1008 Please specify Area-* of the system to which this bug/feature applies. What steps will reproduce the problem? 1.launch chrome os and login 2.go to google.com 3.change search preference to Thai What is the expected output? What do you see instead? Thai accented characters should display fine accent symbol appear way off Thai characters to the left side. cause mis- interpreting the Thai character. see attached screenshots. Thai characters display correctly in Chrome in other OS, even when I install Driod Thai font in my Gunbuntu box, and use a test page select that font, i don't see the same accent off characters issue as in chrome os. Please use labels and text to provide additional information. |
||||||||||||||||||
,
May 03, 2010
(No comment was entered for this change.)
Status: Available
Labels: Mstone-R9 |
|||||||||||||||||||
,
May 05, 2010
It's a bit complicated to explain. There are two issues at play. 1. Droid Sans Thai appears to have a bug with its GPOS/GSUB tables. Uniscribe on WIndows (used by IE, Firefox and Chrome. I tried IE8 on vista and IE7 on XP) and Pango (Firefox and gedit) on Hardy and Harfbuzz (used by Chrome Linux) show some glyphs off the position. I'll talk to Ascender about this issue. 2. In addition, Chrome/Harfbuzz appears to have an issue with some combining marks in Droid Sans Thai. Pango and Uniscribe do not have this problem. Other Thai fonts (Garuda and Loma) do not have a problem with Chrome/Harfbuz, either. So, something in Droid Sans Thai apparently exposes 'incompatibility' of Harfbuzz with Pango/Uniscribe. This has to be filed against Chrome. I'll file one.
Cc: a...@chromium.org e...@chromium.org
|
|||||||||||||||||||
,
May 05, 2010
Ooops. my comment on #1 needs some clarification. : All the browsers on Windows, Mac and Linux (and gedit on Linux) work exactly the same (the position of U+0E4C is too high when it's preceded by U+0E2B). So, it's clearly a font bug. issue #2 happens only with Chrome/Harfbuzz (the issue reported by Vivian). All *other* browsers on Win/Mac/Linux do not have this problem. So, it's more likely to be a Chrome/Harfbuzz issue. |
|||||||||||||||||||
,
Jun 07, 2010
(No comment was entered for this change.)
Labels: -Area-Misc Area-DesktopUI
|
|||||||||||||||||||
,
Jun 09, 2010
#1 issue was fixed by Ascender. We haven't yet received the updated font from Ascender. I'll update the font once I get it. #2 issue is http://crbug.com/43951
Status: Upstream
|
|||||||||||||||||||
,
Jun 25, 2010
I tested the patch http://crbug.com/43951 and it's not fix this issue. So I created a patch for this. It's likely this patch will break somethings. I don't so sure but it work for me. |
|||||||||||||||||||
,
Jun 27, 2010
I believe your patch effectively just sets the offset to zero. The fix is to properly provide some font metrics so that the offset is correct. |
|||||||||||||||||||
| ► Sign in to add a comment | |||||||||||||||||||
