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 <ipp at pwg.org> 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).
>> Do you have any pointers to more information on this?
>> Br,
> Anton
> _______________________________________________
> ipp mailing list
>ipp at pwg.org>https://www.pwg.org/mailman/listinfo/ipp
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://www.pwg.org/pipermail/ipp/attachments/20201015/8c434ce3/attachment.sig>