Justin,
I'll include that in the comments for the next review of PWG Raster (next telecon) and incorporate the changes in the followup draft.
Thanks!
On Apr 20, 2011, at 10:46 AM, Justin Hutchings wrote:
> I think expanding the language in the PWG Raster spec would be very appropriate. Can you take that action item? I’m happy to review/work with you on text for the section.
>> I agree that the IPP everywhere spec should focus on IPP implementations and talking about legacy buses muddies the water.
>> From: Michael Sweet [mailto:msweet at apple.com]
> Sent: Tuesday, April 19, 2011 4:45 PM
> To: Justin Hutchings
> Cc: ipp at pwg.org> Subject: Re: [IPP] PWG Raster intent
>> On Apr 19, 2011, at 10:40 AM, Justin Hutchings wrote:
> Michael,
> I absolutely agree with your point that vendors have their own PDLs today for legacy devices and that it’s unlikely that existing devices will be retrofit. But if vendors begin to transition into IPP and PWG raster, they may choose to reduce their investments in legacy PDLs in order to focus on new technologies. I believe there are some logical conclusions you can draw from this:
>> 1. If a vendor adopts IPP Everywhere and PWG raster with it, then what are the odds they will continue to consume legacy PDLs? The odds of this are low for cost constrained devices such as inkjets. Consuming multiple PDLs requires maintaining separate driver and firmware code bases and becomes prohibitively expensive quickly.
>> Agreed.
>>> 2. If a vendor chooses to only adopt PWG raster as a PDL, but still wishes to target buses that lack an intent protocol, then they will have to create a proprietary intent language.
> a. Though smart buses certainly have advantages, not all clients will implement these buses at the same time and some legacy clients may never be updated. There could be many years where vendors are forced to maintain parallel paths in order to reach all clients they wish to target.
>> PWG Raster *is* based on CUPS Raster, so there is ample room for job ticket information in the page header. We don't use it for IPP Everywhere because it is based on the PostScript page device dictionary, but it has been used successfully for years in CUPS and in some printers to support embedded job ticket information.
>> 3. Therefore, we can expect that during this transitional period, there could be additional cost/pain for vendors that wish to participate in this space. We can mitigate this by being prescriptive about how to represent intent in a PDL stream.
>> I am not opposed to expanding the language in the current PWG Raster spec concerning the page header and why we choose to not use it as a source of embedded job ticket information, e.g. "the CUPS Raster page header contains many embedded job ticket attributes derived from the PostScript page device dictionary, however ..." That should provide enough hints to vendors that want to go down that road to use it for legacy stuff.
>> However, I do not think it is appropriate to make implementation recommendations for interfaces/protocols/buses that are out-of-scope for IPP Everywhere, particularly when those paths do not support the PWG semantic model.
>> __________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
________________________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
--
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/ipp/attachments/20110420/1815d291/attachment-0001.html>