On Sat, 16 Jun 2001, Roozbeh Pournader wrote:
>   9.1 Planes Reserved for future standardization
>
>   Planes 11 to FF in Group 00 and all planes in all other groups (i.e.
>   Planes 00 to FF in Groups 01 to 7F) are reserved for future
>   standardization, and thus those code positions shall not be used for any
>   other purpose.
>
>   Code positions in these planes shall do not have a mapping to the UTF-16
>   form (See Annex C).
>
>     NOTE - To ensure continued interoperability between the UTF-16 form
>     and other coded representations of the UCS, it is intended that no
>     characters will be to code positions in Planes 11 to FF in Group 00
>     and all planes in all other groups.
>
> And continuing to remove any evidence of private use planes E0-FF. This
> would make Markus's idea for using those planes for ISO 2022 compatiblity
> non-conformant, among other things.

"Non-conformance" is a matter of how carefully you word a specification.
There is nothing non-conformant with specifying that in ISO 2022 locales,
wchar_t shall contain in the least-significant 21-bits a UCS value and in
the remaining 10 bits auxiliary information, such as an ISO IR number or
even a squeezed ISO 2022 designator sequence (6 bits for the final
character 0x40-0x7f, 4 bits for the intermediate character 0x20-0x2f,
etc.) Dropping the idea of squeezing everything into UCS private groups
gives us even more space for the auxiliary information.

Markus


-
Linux-UTF8:   i18n of Linux on all levels
Archive:      http://mail.nl.linux.org/linux-utf8/

Reply via email to