[WIMS] Re: [PDL versions?] PWG last call - Command Set Format - IEEE1284 Device ID -25 Feb 2010

[WIMS] Re: [PDL versions?] PWG last call - Command Set Format - IEEE1284 Device ID -25 Feb 2010

[WIMS] Re: [PDL versions?] PWG last call - Command Set Format - IEEE1284 Device ID -25 Feb 2010

Ira McDonald blueroofmusic at gmail.com
Wed Jan 27 20:29:14 UTC 2010


Hi Jerry,

The short answers to your questions are:

(1) Distinguishing Emulation from Genuine was not a
design objective.

(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
to propose?

Or an interoperable Emulation versus Genuine suffix
format?

Cheers,
- 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
winter:
 579 Park Place  Saline, MI  48176
 734-944-0094
summer:
 PO Box 221  Grand Marais, MI 49839
 906-494-2434


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
>
> To
>
> "William Wagner" <wamwagner at comcast.net>
>
> cc
>
> Subject
>
> Re: [Pwg-Announce] PWG last call - Command Set Format - IEEE1284 Device
>    ID -25 Feb 2010
>
>
>
>
>
> Bill,
>
> 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
> support
> 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.
> Example:
> 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,
> PJL;
>
> _____________________________________
>
> [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
> thrasher(at)lexmark(dot)com
>

-- 
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...
URL: <http://www.pwg.org/pipermail/wims/attachments/20100127/fbc41b22/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 3457 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/wims/attachments/20100127/fbc41b22/attachment-0001.gif>


More information about the wims mailing list