[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
Thu Jan 28 17:46:30 UTC 2010


Hi,

Jerry - to address your specific concerns:

(1) Currently IANA Printer MIB includes
      - langPCL(3)
      - langHPGL(4)
      - langPJL(5)
      - langPS(6)
      - langPCLXL(47)
      - langPDF(54)

(2) IANA is very responsive (days) about
registering new values, so adding (for
example) langPDFis, langPS2, langPDF4,
etc., is feasible and practical.

I suggest that registering new values with
IANA is preferable to a (probably not
interoperable) optional use of version
suffixes.

I agree that the Genuine versus Emulation
issue is important for product claims and
for customers - I just don't think we should
try to shoehorn it into IEEE 1284 Device ID.

Bill - due to repeated changes of our mail
server, PWG Steering Committee decided
several years ago to only put this generic
reference to mailing list subscription info
in our specs:

  http://www.pwg.org/mailhelp.html

Cheers,
- Ira

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 Thu, Jan 28, 2010 at 10:22 AM, Jerry Thrasher <thrasher at lexmark.com>wrote:

>
> Re the questions that were raised (not to the point of last call comments
> but I guess they should be discussed)
>
> The question about distinguishing the difference between an Emulation and
> "Genuine" is not a concern
> about interoperability, but if there is a legal requirement to make the
> distinction. We are checking on the
> history of this "requirement" internally, if others on the list have an
> opinion, please share.
>
> The question about distinguishing versions of PDLs really comes down to the
> user experience, and if
> the potential interoperability issues are acceptable to those who want to
> parse the string. I'd like to hear
> Mike Sweet's take on this.  Specific examples of this are fairly easy to
> cite.
>
> (If a device only supports PCL 3, but simply advertizes PCL, and is sent a
> PCL 5 or 6 job that uses HP-GL2 from the host,
> there will be interoperability problems)
> (Another variant on the versioning issues is if a device only supports PDF
> I/S, and only advertizes PDF, and is sent PDF V4,
> there may be memory issues with processing the job.)
>
> A very quick scan of vendor web pages and their claimed PDL support .
>
> Lower end inkjet printers and MFDs support, HP PCL 3 GUI, HP PCL 3 Enhanced
>
> Lower end lasers that support "standard PDLs" support, Postscript 3, PCL 6,
> PCL 5e
>
> (Sample from four different vendor web sites, all with list prices under
> $300.00 USD)
>
> _____________________________________
>
> [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
>
>
>  *"William Wagner" <wamwagner at comcast.net>*
>
> 01/27/2010 09:01 PM
>   To
> "'Ira McDonald'" <blueroofmusic at gmail.com>
> cc
> <wims at pwg.org>, "'Jerry Thrasher'" <thrasher at lexmark.com>
> Subject
> RE: [PDL versions?] PWG last call - Command Set Format - IEEE1284
> Device ID -25 Feb 2010
>
>
>
>
> Hi Ira,
>
> Understood … but I believe it is more polite to ask permission before
> posting to the list emails sent privately.
>
> I simply suggested that, to satisfy the requirements you listed in the
> document, it is necessary to be able to understand what the PDL is, and
> because there are differences in emulations and versions, it may be
> necessary that the reader be aware of the emulation or version.  If there is
> no way of providing this information, then interpreter either has to deal
> with a PDL that is not quite what it says it is, or it has another private
> PDL to accommodate. In either case, the underlying objective of the
> specification is compromised. Currently, although the string may not be as
> machine readable as desired, that information about version and emulation is
> available.
>
> I believe that these are valid points to be considered both by printer
> manufacturers and those reading the string. It may well be that, rather than
> provide incomplete information, it would be better to use the current
> approach.
>
> Bill Wagner
>
> *From:* Ira McDonald [mailto:blueroofmusic at gmail.com] *
> Sent:* Wednesday, January 27, 2010 8:13 PM*
> To:* William Wagner; Ira McDonald*
> Cc:* wims at pwg.org; Jerry Thrasher*
> Subject:* Re: [PDL versions?] PWG last call - Command Set Format -
> IEEE1284 Device ID -25 Feb 2010
>
> Hi Bill,
>
> [please read the mail headers in this thread]
>
> I already PUT it on the WIMS WG mailing list - because ALL
> PWG Last Call comments are supposed to be publicly posted
> and archived.
>
> I do not find any basis for document format variants in the
> requirements you quoted.
>
> And the basic method (using Printer MIB enum labels) has
> been unchanged (and unchallenged) ever since Mike Sweet
> originally proposed this standard at the Open Printing Summit
> in Montreal in fall 2007 and the PWG SC agreed to look into
> it (i.e., it became my long-standing action item).
>
> This interoperable labeling of document format variants (which
> is NOT possible in Printer MIB) is a major new requirement.
>
> Allowing document format variant labeling may be possible
> with some suffix syntax, but *interoperable* document format
> variant labeling is simply impossible.
>
> Vendors don't currently use the same version numbers to
> mean the same thing, and it's way out-of-scope for this
> specification to solve *that* problem.
>
> Cheers,
> - Ira
>
> 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* <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 5:41 PM, William Wagner <*wamwagner at comcast.net*<wamwagner at comcast.net>>
> wrote:
> Do either of you object if we put this on the PMP/WIMS mailing list and
> include it in the face-to-face discussion?
>
> With respect to Ira’s comments, one may argue that design requirements  5-7
>
> ·         should support automatic device driver installation by client
> and server operating systems (see section 3.2).
>
> ·         should support interoperable advertising of implemented document
> formats by network spoolers and network Printers (see sections 3.1 and 3.2).
>
> ·         should support interoperable discovery of available document
> formats by Imaging Clients and Imaging Servers (see sections 3.1 and 3.2).
>
> would suggest a document format method that did distinguish between
> variations on a language without the need for creating a  slew of
> vendor-specific language identifications.
>
>
>
> Thanks,
>
>
>
> Bill Wagner
>
> *From:* Ira McDonald [mailto:*blueroofmusic at gmail.com*<blueroofmusic at gmail.com>]
> *
> Sent:* Wednesday, January 27, 2010 3:29 PM*
> To:* William Wagner; *wims at pwg.org* <wims at pwg.org>; Ira McDonald*
> Cc:* Jerry Thrasher*
> Subject:* Re: [PDL versions?] PWG last call - Command Set Format -
> IEEE1284 Device ID -25 Feb 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* <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*<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* <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/20100128/969b9491/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 3457 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/wims/attachments/20100128/969b9491/attachment-0002.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 3457 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/wims/attachments/20100128/969b9491/attachment-0003.gif>


More information about the wims mailing list