[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Encoding of etc/HELLO

From: Juri Linkov
Subject: Re: Encoding of etc/HELLO
Date: Mon, 23 Apr 2018 23:05:08 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu)

>> I don't understand why it's impossible to create a charset like the
>> existing mule-unicode-e000-ffff but for character range over U+FFFF
>> to include such characters as U+1F44B.  Or is this an inherent limitation
>> of the iso-2022-7bit coding system?
> I'm not sure I understand your proposal.  Are you suggesting to create
> a Mule charset covering just the Emoji block?  That could be possible
> (assuming ISO-2022 still has vacant charset slots available, something
> that I don't think I know how to determine reliably, and assuming we
> decipher the black art of using define-charset).  But is this worth
> doing it just for Emoji?
> If you mean to add a larger range of characters, then I think a single
> ISO-2022 compatible charset can support at most 8192 character, so we
> will need a lot of charsets to cover codepoints between U+10000 and
> U+2FFFF, and I'm not sure we have that many vacant slots.
> Or did you mean to suggest something else?

This is exactly what I meant.  While using ISO-2022 encoding in HELLO
to represent Unicode characters is just an inconvenience, the inability
to encode all Unicode characters in ISO-2022 is a serious limitation.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]