[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Encoding of etc/HELLO
From: |
Eli Zaretskii |
Subject: |
Re: Encoding of etc/HELLO |
Date: |
Mon, 23 Apr 2018 19:25:41 +0300 |
> From: Juri Linkov <address@hidden>
> Cc: Paul Eggert <address@hidden>, Eli Zaretskii <address@hidden>,
> address@hidden
> Date: Sat, 21 Apr 2018 23:31:22 +0300
>
> 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?
Re: Encoding of etc/HELLO, Paul Eggert, 2018/04/20