The short answers to your questions are:
(1) Distinguishing Emulation from Genuine was not a
(2) Distinguishing PDL versions was also not a design
objective (or plausibly interoperable).
- The use and misuse of the corresponding version
elements in the Printer MIB v1/v2 prtInterpreterTable
is a hopeless mess.
- Nobody was willing to let the editors to address this
when we did Printer MIB v2.
So, inserting version information may work for a given
vendor, but completely breaks interoperability across
different spoolers and OS environments.
We could perhaps introduce a syntax for version
suffixes, but the chances that vendors will correctly
implement it seems very unlikely.
Bearing in mind the machine-readability imperative,
do you have an interoperable version suffix format
Or an interoperable Emulation versus Genuine suffix
- Ira (1284 Cmd Set editor)
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Co-Chair - TCG Hardcopy WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
579 Park Place Saline, MI 48176
PO Box 221 Grand Marais, MI 49839
On Wed, Jan 27, 2010 at 11:58 AM, William Wagner <wamwagner at comcast.net>wrote:
> Hi Jerry,
>>>> I am sending your questions onto Ira. I think your two points are very good
> ones. My take on them:
>>>> The spec allows for PrtInterpreterLangFamilyTC, mime-media-type, and Private
> type designations. PrtInterpreterLangFamilyTC does not provide for version
> and emulation variations; mime-types for all of the variations do not exist,
> and would be cumbersome if they were to be all registered; and having
> applications understand the difference between private types is unrealistic.
>>>> The intent is machine identification of the command language. Just
> indicating (by an appropriate means… placing “emulation” after the
> designation does not appear consistent with the spec) that a pdl is an
> emulation warns the interpreter that there may be differences from the
> defined set, but these will likely be different from one emulation to
> another. I think the best approach depends on how good the emulation is (as
> an emulation, not as a PDL). But, barring having to define and designate
> each emulation as a separate PDL, there might be some benefit in somehow
> flagging that a PDL might deviate somewhat from the defined language.
>>>> Major Version differences are likely more drastic, more likely to be
> independently defined and since there should be fewer of them that possible
> emulations, more amenable to being listed as separate MIB or MIME types.
> That is, there is little advantage in knowing the language is up-version
> (other than expecting differences) unless the interpreter knows what the
> differences are. To be able to do this, the version and its definitive
> reference should be identified in a standard way. The problem then, of
> course, is who is going to register these versions.
>>>> Thanks for the input.
>>>> Bill Wagner
>>>>>> *Jerry Thrasher/Lex/Lexmark*
>> 01/27/2010 09:07 AM
>> "William Wagner" <wamwagner at comcast.net>
>> Re: [Pwg-Announce] PWG last call - Command Set Format - IEEE1284 Device
> ID -25 Feb 2010
>> A couple of questions have come up with respect to what's really required
> to be done and what
> can be done with respect to two particular issues.
> 1. The percieve requirement for not confusing PDL emulation with "true" PDL
> Example, Postscript Emulation vs. Adobe PostScript and PCL Emulation vs. HP
> PCL support.
> 2. The need for the ability for versioning of the various PDLs.
> PCL 6 is very different from PCL 3 (most low end inkjet printers still
> support only PCL 3, the first
> PCL to support color).
>> So here's what I'm talking about from a real string.
> If the current CMD string is:
>> COMMAND SET:PCL 6 Emulation, PostScript Level 3 Emulation, NPAP, PJL;
>> Would a compliant string simply be:
>> COMMAND SET:PCL,PS,PCL 6 Emulation, PostScript Level 3 Emulation, NPAP,
>> [image: LEXMARK] *
> Jerry Thrasher*
> Senior Engineer, WW Corporate Standards
> C14/082-1, 740 New Circle Rd, Lexington Ky 40550
> Office: +1 859 825 4056 Fax: +1 859 232 7628
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3457 bytes
Desc: not available