Charset niggles

Charset niggles

[Lars Magne Ingebrigtsen]

(I'm now playing in Emacs 20.3, but I'm guessing this applies to all
MULE Emacsen.)

On Amharic and Tigrana, char-charset says `ethiopic', and the
prefered-coding-system is reported as `iso-2022-jp'.  However, when I
decode what I get, I don't get anything; just escape sequences.  But
if I decode what I got as `iso-2022-jp-2', I get back the Amharic and
Tigrana.

On the other hand, the Japanese in the HELLO file can be encoded and
decoded as `iso-2022-jp' OK.

Er...  Does this mean that it's just a faulty prefered-coding-system
in Emacs 20.3 for `ethiopic'?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Magne Ingebrigtsen

Charset niggles

[Stephen J. Turnbull]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

    Lars> (I'm now playing in Emacs 20.3, but I'm guessing this
    Lars> applies to all MULE Emacsen.)

I don't think Ethiopic is supported before Emacs 20.x, and XEmacs
includes the code but does not load it by default (due to a bug
probably in some X servers).  With no Ethiopic speakers on board,
XEmacs can hardly say it's "supported" :-( but we'd love to get bug
reports (and even more so ecstatic reports from happy users :-).

    Lars> On Amharic and Tigrana, char-charset says `ethiopic', and
    Lars> the prefered-coding-system is reported as `iso-2022-jp'.
    Lars> However, when I decode what I get, I don't get anything;
    Lars> just escape sequences.  But if I decode what I got as
    Lars> `iso-2022-jp-2', I get back the Amharic and Tigrana.

Yes.  I believe that iso-2022-jp-2 (aka iso-2022-cjk aka
iso-2022-int-1, if I recall correctly) is a very slight redesign of
iso-2022-jp to make sure that non-Japanese character sets are handled
correctly.

ITRC the history of the RFCs was that people "accidently" got good
results from using iso-2022-jp with non-Japanese character sets (not
surprising, that robustness was an important design consideration in
the ISO-2022 spec), and the -jp-2 version was specifically created
with this in mind.  Possibly some recent Emacs tightened up the Mule
definition of -jp to "Japanese-only."

I wouldn't be surprised if practically every "unusual" character set
defaults to `iso-2022-jp' for that historical reason, and nobody's
systematically gone about cleaning it up yet.

    Lars> Er...  Does this mean that it's just a faulty
    Lars> prefered-coding-system in Emacs 20.3 for `ethiopic'?

Yes.  Look at the iso-2022-int* coding systems; that's more likely to
make sense to non-Japanese users, and should work as well.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
__________________________________________________________________________
__________________________________________________________________________
What are those two straight lines for?  "Free software rules."

Re: Charset niggles

[Lars Magne Ingebrigtsen]

"Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp> writes:

>     Lars> Er...  Does this mean that it's just a faulty
>     Lars> prefered-coding-system in Emacs 20.3 for `ethiopic'?
> 
> Yes.  Look at the iso-2022-int* coding systems; that's more likely to
> make sense to non-Japanese users, and should work as well.

Thanks; I've now sent a patch to Stallman for defaulting Ethiopic to
iso-2022-7bit, which seems to do the trick.

(Er -- shouldn't that be "Ethiopian"?)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen