[Webkit-unassigned] [Bug 49714] Yensign hack should work with Shift_JIS encoding

[bugzilla-daemon at webkit.org]

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





--- Comment #23 from Kent Tamura <tkent at chromium.org>  2010-12-08 16:05:27 PST ---
(In reply to comment #22)
> (From update of attachment 74536 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=74536&action=review
> 
> > WebCore/ChangeLog:10
> > +        IE chooses a font which shows a yensign for 0x5c code point for a page
> > +        encoded in x-mac-japanese, ISO-2022-JP, EUC-JP, Shift_JIS, Shift_JIS_X0213-2000,
> > +        x-sjis, and Windows-31J.
> 
> I thought IE didn't support Shift_JIS_X0213-2000.

I was surprised when I saw IE switched the default font for it.
I guess IE uses prefix-matching for encoding names.

> > WebCore/ChangeLog:16
> > +        Also, we move the HashSet initialization for isJapanese() and
> > +        backslashAsCurrencySymbol() to TextEncodingRegistry.cpp because of
> > +        ease of making them multi-thread safe.
> 
> This is not a great reason - TextEncodingRegistry does not and should not care about backslashes.

However, the encoding names for backslashAsCurrencySymbol() depend on TextEncodingRegistry.  If one added new Japanese encoding to TextEncodingRegistry, he/she might need to add it to nonBackslashEncodings.

Anyway, I also feel the new code is not good.  I'll add a FIXME comment.

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