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.
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.
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.
Do you agree?
Thanks
Justin
From: Michael Sweet [mailto:msweet at apple.com]
Sent: Monday, April 18, 2011 5:02 PM
To: Justin Hutchings
Cc: ipp at pwg.org
Subject: Re: [IPP] PWG Raster intent
On Apr 18, 2011, at 4:04 PM, Justin Hutchings wrote:
All,
I brought up in the last face to face that a standard mechanism to express intent in PWG Raster is important to ensure that vendor implementations don't fork across "dumb" buses like USB and Bluetooth (HCRP). I'd like to have some more discussion of this topic. If we do not create a common definition, then each vendor will likely create different variants of PWG Raster that includes intent.
I'm not convinced that is the case. Every printer vendor already has their own PDL(s) to support legacy interfaces and protocols - given the development costs associated with adopting a new PDL, why would any vendor choose to do so without a compelling reason? The only useful advantage PWG Raster has over existing vendor PDLs is the use of client-friendly colorspaces, and many vendor PDLs have already made that transition.
The real advantages IPP (and alternate bindings like WS-Print), IPP-over-USB, and Bluetooth BPP have over legacy protocols are:
1. Well-defined model, operations, and attributes for printing, status monitoring, and control
2. Standard job tickets external to the document format
3. Support for identification and submission of multiple document formats
4. Standard extension mechanisms
The goal of IPP Everywhere is to replace those legacy interfaces with IPP and adopt one or more standard document formats and discovery mechanisms (in the case of network printers) so that a single "generic" driver can support all of the common use cases for printing and multifunction with any printer that conforms to the standard. Similarly, vendor-specific drivers can be written and used to support use cases outside of IPP Everywhere while still using the same core protocols.
I see little point in trying to retrofit support for existing printers when they generally cannot be upgraded in the first place. Moreover, printers that *can* be upgraded will likely have the resources to support IPP Everywhere since the vendor already invested in flash storage and the other related hardware necessary to support upgrades. Remember, consumer inkjet printers only recently (2008-2009) started shipping with flashable firmware, and that practice is still far from common - most still ship with everything hardcoded in ASICs and ROMs...
________________________________________________________________________
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/20110419/d92b9ba6/attachment-0001.html>