A quick lesson in coded character sets (I was the chairman of the ANSI
X3L2 committee responsible for ASCII (and worked on ISO 8859 and ISO 10646):
1. The coded character set called ASCII is defined to be the control
characters 0 through 31 and the printing characters 32 (SPACE) through
126. 127 is DEL (a control) and 128 to 255 are NOT part of the ASCII
coded character set. So ASCII is really a 7-bit set that is usually
embedded in an 8-bit transmission, so that the high order bit SHALL be 0.
Unfortunately, people use the term "ASCII" to mean any coded character set,
such as the PJL manual. (Don't feel bad, you are not alone).
2. ISO Latin-1 (ISO 8859-1) is one of the 8-bit coded character sets which
defined printing characters only: 32 to 126 (same as ASCII fortunately),
and 160 to 255. The characters in 160-255 are accented letters and
special symbols, such as pound and yen, more quotes, etc. There are
at least 11 8-bit coded character sets defined by ISO 8859-n.
The windows default character set is ISO Latin-1 plus Microsoft filled
in additional characters in the unspecified space: 128-159.
HP has an 8-bit coded character set that is similar to ISO Latin-1.
(I've forgotten the name).
Presumably, if a PJL printer gets an attribute with the 8th bit set,
and that is the value of an attribute that the Printer prints on
the banner page, such as the user's name, then some coded character
set is being used for the codes in the range 128-255.
So what does PJL do with characters greater than 127?
Is it ISO Latin-1?
Is it the HP 8-bit set?
Is is Windows default 8-bit set?
Unspecified so it can be any?
The administrator can set the default set locally for the printer?
Thanks,
Tom
At 15:33 07/09/97 PDT, Bob Pentecost wrote:
>Harry,
>>You are very close to being correct. To quote the PJL Tech Ref Manual, PJL
"strings consist of any combination of characters from ASCII 32 through 255,
plus ASCII 9 (horizontal tab), excluding ASCII 34 (quotation marks)." There
is no localization information provided.
>>Bob
>>>----------
>From: Harry Lewis[SMTP:harryl at us.ibm.com]
>Sent: Wednesday, July 09, 1997 3:32 PM
>To: hastings at cp10.es.xerox.com>Cc: jmk at underscore.com; bpenteco at boi.hp.com; rbergma at dpc.com>Subject: Localization in the Job MIB
>>Tom, I think it was David Perkins who wrote (about the Job MIB)...
>>>For simplicity, this specification assumes that the clients, job monitoring
>>applications, servers, and devices are all running in the same locale.
>>However, this specification allows them to run in any locale, including
>>locales that use two-octet coded character sets, such as ISO 10646
>>(Unicode). Job monitors applications are expected to understand the coded
>>character set of the client (and job), server, or device. No special means
>>is provided for the monitor to discover the coded character set used by jobs
>>or by the server or device. This specification does not contain an object
>>that indicates what locale the server or device is running in, let alone
>>contain an object to control what locale the agent is to use to represent
>>coded character set objects.
>>While I sympathize with the localization problem - (I think I'm beginning
>to understand Ira's arguments as they pertain to the Printer MIB), I think
>we have a real limitation in the Job MIB in that we are ultimately limited
>by the Job Submission protocol or language. Bob can correct me if I'm wrong,
>but if we take PJL as an example of a pervasive submission language the
>attributes passed in will be limited to ASCII characters 32 to 225 plus
>"tab". I don't think there is a way to localize these strings or for the
>agent to determine the local - but I could be wrong.
>>If we want to do something to accommodate submission protocols which *do*
>facilitate localization of passed in attributes, we may entertain this,
>but only if it allows for status-quo as a default.
>>Harry Lewis - IBM Printing Systems
>>>>