[Webkit-unassigned] [Bug 24906] 0x5C of EUC-JP is not Yen Sign but U+005C

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=24906





------- Comment #30 from jshin at chromium.org  2009-04-07 14:09 PDT -------
(In reply to comment #21)
> Internally, I'm getting a different input - it would not be acceptable to break
> the display of yen sign. Really, if it were ok, Microsoft would have removed
> this quirk from its fonts years ago, I'm sure it's a pain for them to have it.

MS could have fixed the problem a long time ago at least when they released
Windows XP (i.e. when their main line OS became fully Unicode-aware/capable.
Win 2k and NT4 were also Unicode-capable/aware, but Win 9x/ME were a lot more
widespread than Win 2k/NT4). See my argument on the issue at
http://unicode.org/mail-arch/unicode-ml/y2002-m10/0340.html

JA/KO fonts shipped with Windows are not compliant to the Unicode standard. I
don't think even MS people would say that the identity of U+005C depends on a
font being used to render it. However, that's exactly what they do with fonts
like MS (P) Gothic/MS (P) Mincho and Gulim/Batang(che). 

<span style="font-family: MS P Gothic">\</span>
<span style="font-family: Gulim">\</span>

The above snippet (in any encoding, UTF-8,16, EUC-JP, EUC-KR) rendered on
Windows with two fonts installed will have 'Yen' and 'Won' glyphs in place of
'\'. 

> Currently, this bug doesn't have any examples of pages that work in IE
> properly, but do not work in Safari (http://doc.okkez.net/187/view/spec/regexp
> looks in IE exactly as it does in Safari, even though the rendering can be
> considered wrong). Without any known affected sites, the priority of this issue
> is very low, see <http://webkit.org/quality/bugpriorities.html>.
> 


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.