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/