W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2012

[whatwg] iso-2022-jp and octets over 0x7E

From: NARUSE, Yui <naruse@airemix.jp>
Date: Mon, 09 Jan 2012 06:03:37 +0900
Message-ID: <4F0A04A9.2040906@airemix.jp>
(2012/01/09 4:49), Anne van Kesteren wrote:
> On Sun, 08 Jan 2012 15:32:47 +0100, Anne van Kesteren <annevk at opera.com> wrote:
>> On Sun, 08 Jan 2012 01:37:14 +0100, NARUSE, Yui <naruse at airemix.jp> wrote:
>>> == iso-2022-jp
>>> === The to Unicode algorithm
>>> ==== Based on iso-2022-jp state
>>> ===== ASCII state
>>> ====== Based on octet:
>>> ======= Otherwise
>>>> If the fatal flag is set, return failure.
>>>> Otherwise, emit the fallback code point.
>>>
>>> Just FYI, IE and Opera show these bytes as Katakana.
>>> If octet is greater than 0xA0 and less than 0xE0, value is octet + 0xFEC0.
>>>
>>> Moreover IE shows any shift_jis characters here.
>>> It seems that IE uses the same converter both iso-2022-jp and shift_jis.
>>
>> I have filed a bug on Opera to become more strict like Webkit/Gecko. If there is some evidence that approach is wrong though, we can turn it around.
> 
> So just to be sure I checked again and in Opera you can only get the "special" single-octet behavior if you active a particular state first. If you are in ASCII, Opera will simply emit the octet unless it is 0x1B (ESC) so maybe there is a system font that does something special for those characters? Or maybe you meant something else?

Ah, you are correct.
Opera's behavior is different from IE and it is clearly wrong.

-- 
NARUSE, Yui  <naruse at airemix.jp>
Received on Sunday, 8 January 2012 13:03:37 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:10 UTC