I certainly agree that keeping track of the language and country for
such POSIT objects isn't very useful. But isn't the character set useful?
But does not including these POSTIT objects under prtGeneralStaticCodeSet
make this solution more acceptable?
>> 3. Is there an identified need for the printer to use a character set
>> other than UTF8 for the remaining, largely read only objects?
>I suggest yes, in order to handle existing practice of the 5si using
>HP Roman 8 and Lexmark using their 8-bit set. However, we want to steer
>future implementations towards UTF8 only as recommended by the IAB in
>RFC 2130. Thus the DEFVAL 106. Even RFC 2130 doesn't preclude other
>WW: I guess I was hoping that HP and Lexmark did not need their specific
>character sets for the non-user entered objects I had listed.
I think that the reaons Bob supported yesterday's proposal was that it
reflected the 5si practice.
>> 4. LocalizationLanguage (ISO639) and LocalizationCountry (ISO3166) are
>> two character codes (with a size constraint to 2 octets); would these
>> be recognizable/enterable in any likely character set to be specified?
>No. They are always in English as specified in ISO 3166 and ISO 639.
>Since any set that could be specified by prtGeneralCodeSet MUST preserve
>code positions 32-126 as US-ASCII, the values of language and country are
>unaffected by prtGeneralStaticCodeSet by definition.
>WW: OK, I guess I need some facts. You are saying that JIS X0208-1990 and GB
>2312-1980, for example, will revert to one byte per character US ASCII if the
>first byte is a US ASCII code?
Yes, according to ISO 2022 and actual practice in Japan and China, the
two byte Kanji set consists of bytes with the 8th bit set, i.e., both bytes
are in the code range 128 to 255. Bytes in the range 32 to 126 are US-ASCII
and are single byte characters. Thus they are dealing with one and two bytes
characters at the same time. But UTF-8 is a variable byte set as well,
with characters taking one, two, or three bytes.
I was chairman of the US X3 Codes and Character Sets committee for a number
of years, called X3L2. X3L2 was responsible for US-ASCII and the US positions
on ISO 2022, ISO 8859, and ISO 10646. So I'm real familiar with the code
>> Bill Wagner, Osicom/DPI