Subject: [IPP] PWG Raster intent

From: Justin Hutchings <[email-masked]>
Date: Mon, 18 Apr 2011 23:04:16 +0000

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.

Do we have an existing format that would be easily incorporated into the PWG Raster spec? Would it make sense to have some kind of serialized IPP-intent stream?

Thanks!
Justin

Justin Hutchings | Program Manager | Windows\DNT\DeviceConnectivity::Printing and Imaging

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Mon, 18 Apr 2011 17:02:28 -0700

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

---

From: Justin Hutchings <[email-masked]>
Date: Tue, 19 Apr 2011 17:40:06 +0000

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:[email-masked]]
Sent: Monday, April 18, 2011 5:02 PM
To: Justin Hutchings
Cc: [email-masked]
Subject: Re: [IPP] PWG Raster intent

---

From: Michael Sweet <[email-masked]>
Date: Tue, 19 Apr 2011 16:44:57 -0700

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:
>  

Agreed.

> 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 vend…

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 prescri…

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

---

From: Justin Hutchings <[email-masked]>
Date: Wed, 20 Apr 2011 17:46:22 +0000

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:[email-masked]]
Sent: Tuesday, April 19, 2011 4:45 PM
To: Justin Hutchings
Cc: [email-masked]
Subject: Re: [IPP] PWG Raster intent

Agreed.

---

From: Michael Sweet <[email-masked]>
Date: Wed, 20 Apr 2011 10:53:04 -0700

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.
>