Subject: [IPP] Redundancies between IPP attributes and PWG-raster header

From: Anton Thomasson via ipp <[email-masked]>
Date: Thu, 15 Oct 2020 21:23:32 +0200

Hi

I am the developer of a very simple printing app for Sailfish OS that goes
by the name "SeaPrint".

>From my experimentation with raster formats, I have found that there are
several IPP attributes that describe things that need/should be set in the
(PWG-)raster header.
It has even been the case that setting attributes on IPP itself that are in
agreement with the value in the raster header, jobs would not be accepted
by my printer(s).

Is there any reason/background to this that would be good to know in order
to understand it better?

I cannot seem to find anything conclusive on whether a well-behaved app
should indeed have to do this (although it seems reasonable), nor exactly
which attributes may not appear on IPP when using PWG-raster.
For simple things like Copies, Sides etc. the mapping is pretty
self-explanatory, and the table in 4.3 of the PWG raster spec makes sense.
But for media-col for example, it is not as obvious how to split up its
components (or indeed if some things that can appear in it need to be left
in IPP as it has no corresponding header attribute).

Do you have any pointers to more information on this?

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

---

From: "Kennedy, Smith \(Wireless & IPP Standards\) via ipp" <[email-masked]>
Date: Thu, 15 Oct 2020 19:51:47 +0000

Hi Anton,

If I remember correctly, the redundancy was in part to decouple PWG Raster as a document format from having dependencies on IPP as the transport over which it is sent. I'm sure Mike Sweet will have additional comments, but I believe that was at least one of the underlying concerns.

Smith

/**
    Smith Kennedy
    Chair, IEEE ISTO Printer Working Group
    HP Inc.
*/

> On Oct 15, 2020, at 1:23 PM, Anton Thomasson via ipp <[email-masked]> wrote:
> 
> Hi
> 
> I am the developer of a very simple printing app for Sailfish OS that goes by the name "SeaPrint".
> 
> From my experimentation with raster formats, I have found that there are several IPP attributes that describe things that need/should be set in the (PWG-)raster header.
> It has even been the case that setting attributes on IPP itself that are in agreement with the value in the raster header, jobs would not be accepted by my printer(s).
> 
> Is there any reason/background to this that would be good to know in order to understand it better?
> 
> I cannot seem to find anything conclusive on whether a well-behaved app should indeed have to do this (although it seems reasonable), nor exactly which attributes may not appear on IPP when using PWG-raster.
> For simple things like Copies, Sides etc. the mapping is pretty self-explanatory, and the table in 4.3 of the PWG raster spec makes sense.
> But for media-col for example, it is not as obvious how to split up its components (or indeed if some things that can appear in it need to be left in IPP as it has no corresponding header attribute).
>

---

From: Michael Sweet via ipp <[email-masked]>
Date: Thu, 15 Oct 2020 16:24:44 -0400

Anton,

> On Oct 15, 2020, at 3:23 PM, Anton Thomasson via ipp <[email-masked]> wrote:
> 
> Hi
> 

Generally, the page header is provided to support per-page overrides (size and/or source, typically) and a mix of color and grayscale pages in order to optimize printing.

Unfortunately, we don't have an implementor's guide for PWG Raster, but my personal advice is to have the page header match the job attributes.  The CUPS cupsRasterInitPWGHeader function can be used to initialize the page header consistent with the job attributes.

________________________
Michael Sweet

---

From: Anton Thomasson via ipp <[email-masked]>
Date: Sat, 17 Oct 2020 13:24:30 +0200

Michael,

Thanks for the insight!
It made me do a fresh take on the issue with my printers rejecting jobs.
Turns out it was regardless of format, and due to me encoding the
attributes in question as Enum instead of Keyword.

Serves me right for implementing my own IPP (and raster) codecs. :)
(Kudos for good reference material!)
Indeed, reading cupsRasterInitPWGHeader was also really helpful in this,
and i should be revisiting it.

Again, thanks for sorting me out.

Br,
Anton

Den tors 15 okt. 2020 kl 22:24 skrev Michael Sweet <[email-masked]>:

> > It has even been the case that setting attributes on IPP itself that are
> in agreement with the value in the raster header, jobs would not be
> accepted by my printer(s).
> >
> Generally, the page header is provided to support per-page overrides (size
> and/or source, typically) and a mix of color and grayscale pages in order
> to optimize printing.
>
> Unfortunately, we don't have an implementor's guide for PWG Raster, but my
> personal advice is to have the page header match the job attributes.  The
> CUPS cupsRasterInitPWGHeader function can be used to initialize the page
> header consistent with the job attributes.
>
> ________________________
> Michael Sweet
>
>
>
>