[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

Jerry Thrasher thrasher at lexmark.com
Thu Jan 28 15:22:51 UTC 2010


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)

_____________________________________
 
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
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> 
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] 
Sent: Wednesday, January 27, 2010 3:29 PM
To: William Wagner; 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
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; 

_____________________________________ 
 
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/e1923dee/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/e1923dee/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/e1923dee/attachment-0003.gif>


More information about the wims mailing list