I think the problem gets a lot worse when UTF-8 becomes involved. With =
non-encoded strings, the worst that happens is an incorrect mapping of =
the characters that have the eighth bit set (assuming the 7 bit =
characters are ASCII). A management application that is expecting UTF-8 =
will take a character with the eighth bit set and then will consume the =
next two, three or four characters and display a single character. I =
would bet that the resulting string in the first case is a lot easier to =
understand than the resulting string in the second (UTF-8) case.
Bob
----------
From: Bill Wagner[SMTP:bwagner@digprod.com]
Sent: Friday, July 25, 1997 5:09 PM
To: 'PWG-pmp'
Subject: Re: PMP> Management app expecting UTF-8 question
=20
Bob,=20
=20
It would seem to me that, in the general case, a management=20
application would have no idea what character set the =
'misbehaving'=20
printer agent supports, whether or not we decide to go with the =
UTF-8=20
proposal. In a specific case where the management agent 'knows' =
that a=20
particular printer will use PC-850 or whatever, it will know that =
in=20
either case.
=20
Bill Wagner, Osicom/DPI=20
______________________________ Reply Separator =
_________________________________
Subject: PMP> Management app expecting UTF-8 question
Author: Bob Pentecost <bpenteco@boi.hp.com> at Internet
Date: 7/25/97 3:57 PM
If we decide to go with the UTF-8 proposal, how will a management =
application=20
distinguish between a newer printer that is using UTF-8 and an older=20
"misbehaving" printer that is using non-ASCII (such as PC-850 or Roman-8 =
for two
examples)? The ASCII portion will be displayed correctly, but the =
characters=20
that have the eighth bit set will be misinterpreted.=20
=20
Bob
=20