Re: New Mac OS Changes

[Kenichi Handa]

Andrew Choi <address@hidden> writes:
> The Mac Roman encoding is a distinct (i.e., non-standard) character
> encoding used by Apple.  It includes characters from a number of
> European languages and its own special symbols (e.g., the Apple logo,
> the command key symbol, etc).  It does not seem to map one-to-one to
> any of the existing character sets (unlike the DOS codepages).

> A coding system called mac-roman is indeed defined in mac-win.el which
> uses these character sets (mac-roman-lower and mac-roman-upper).  It
> is used to display Mac files in their native encoding and for
> displaying file names, for example.

> Conceivably we can make this coding system available on other
> platforms if fonts for such an encoding are created for them and there
> is ever a need to edit Mac Roman files there.  But then we can always
> use recode (and perhaps lose a few characters).

I've just checked this page:
  ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMAN.TXT
and found that only the following characters are not yet
supported by Emacs.

0xD7    0x25CA  # LOZENGE
0xDE    0xFB01  # LATIN SMALL LIGATURE FI
0xDF    0xFB02  # LATIN SMALL LIGATURE FL
0xF0    0xF8FF  # Apple logo

All the others are in ascii, latin-iso8859-X, or mule-unicode-0100-24ff.

So, how about supporting more Unicode characters by
introducing these two charsets instead of
mac-roman-lower/upper:
        mule-unicode-2500-33ff (before the start of CJK Ideographs)
        mule-unicode-e000-ffff (Private Use and Compatibility)
(I think that having more non-Unicode private character sets
makes the shift to Unicode more difficult)

Then, we can cover not only all mac-roman characters, but
also all Unicode BMP characters in non-CJK area.
Miyashita-san can easily update his package Mule-UCS for
supporting these new characters.

Writing a coding system (and CCL program for Monaco font)
for mac-roman encoding is easy.

If you agree with this method, I'll work on it quickly.  For
the moment, I see no technical difficulty, and beleive that
it doesn't break any existing codes.

---
Ken'ichi HANDA
address@hidden