attachment
<div dir="ltr">Thank you for all the replies! They were very helpful.<div><br></div><div>Best regards,</div><div>Piotr</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Thu, Feb 26, 2026 at 11:20 AM Michael Sweet <<a href="mailto:msweet@msweet.org">msweet@msweet.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Piotr,<br>
<br>
> On Feb 25, 2026, at 10:40 PM, Piotr Pawliczek via ipp <<a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a>> wrote:<br>
> <br>
> <br>
> Hello Everyone,<br>
> <br>
> I am looking for guidance on the best approach for handling larger rasters. Specifically, what is the current recommended method for raster compression?<br>
> <br>
> There is a "compression-supported" IPP attribute that allows the client to apply compression to the IPP payload. However, for many printers this attribute contains only "none".<br>
<br>
Any AirPrint printer should support the "compression/-supported" attributes with the 'gzip' or 'deflate' values to apply LZ77 compression with the corresponding gzip or deflate headers. For reference, of the 14 printers in my office all but one printer (an entry-level inkjet) supports compression...<br>
<br>
> I cannot find any reference to HTTP-level compression. Is it mentioned in any IPP document? <br>
<br>
IPP doesn't talk about HTTP's Content-Encoding header and I am not aware of any IPP Clients or Printers that use it for IPP requests/responses, so I doubt you would be able to successfully use that generally.<br>
<br>
________________________<br>
Michael Sweet<br>
<br>
</blockquote></div>