Re: Raster compression
Anton Thomasson via ipp <[email protected]> Thu, 26 Feb 2026 19:19:44 +0100
| Newsgroups | gmane.ietf.ipp |
|---|---|
| Message-ID | <CABFDNXTnThRPEc+_jzHdrsiWUa3CXiX2=brS4w1_1dy256S8Gw@mail.gmail.com> |
--===============8573385877260898573== Content-Type: multipart/alternative; boundary="00000000000001dd03064bbe2b9d" --00000000000001dd03064bbe2b9d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi It seems highly unlikely that a printer would accept http-level compression, but fail to advertise it for IPP playload. These are very resource-constrained systems. And how would you detect support? The rasters already have a rudimentary RLE compression that is pretty decent (~10:1) for text and graphics (but not photos). With today's network speeds (or even those of 10+ years ago where many printers seem to be stuck) you are already easily surpassing the physical output of the printer. Do you really need to go any faster? The recommendation is to apply compression when supported. Some printers do seem to perform better when receiving raster that is gzipped or deflated as well - many don't seem to care. Hopefully printers not supporting compression have a large enough buffer to not get starved. How large is large - and do you have any specific problems you are trying to solve? Br, Anton Den tors 26 feb. 2026 kl 10:41 skrev Holger Gr=C3=A4fe via ipp <[email protected]= >: > Hi Piotr, > > you may try whether compression on HTTP level via header field > "Content-Encoding" is accepted by the device. There are various compressi= on > methods defined, e. g. "gzip". However, I'm not sure whether any of them = is > effective for arbitrary raster image data. > You can find more details here: > https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Conte= nt-Encoding > > Best regards, > Holger > > *Gesendet: *Donnerstag, 26. Februar 2026 um 04:40 > *Von: *"Piotr Pawliczek via ipp" <[email protected]> > *An: *"PWG IPP Workgroup" <[email protected]> > *CC: *"Piotr Pawliczek" <[email protected]> > *Betreff: *[IPP] Raster compression > > Hello Everyone, > > I am looking for guidance on the best approach for handling larger > rasters. Specifically, what is the current recommended method for raster > compression? > > There is a "compression-supported" IPP attribute that allows the client t= o > apply compression to the IPP payload. However, for many printers this > attribute contains only "none". > > I cannot find any reference to HTTP-level compression. Is it mentioned in > any IPP document? > > Or is there any other way to deal with large rasters? > > I would appreciate any information. > > Best regards, > Piotr > _______________________________________________ ipp mailing list > [email protected] https://www.pwg.org/mailman/listinfo/ipp > _______________________________________________ > ipp mailing list > [email protected] > https://www.pwg.org/mailman/listinfo/ipp > --00000000000001dd03064bbe2b9d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div>Hi</div><div><br></div><div>It seems= highly unlikely that a printer would accept http-level compression, but fa= il to advertise it for IPP playload.</div><div>These are very resource-cons= trained systems.</div><div>And how would you detect support?</div><div><br>= </div><div>The rasters already have a rudimentary RLE compression that is p= retty decent (~10:1) for text and graphics (but not photos).</div><div>With= today's network speeds (or even those of 10+ years ago where many prin= ters seem to be stuck) you are already easily surpassing the physical outpu= t of the printer.</div><div>Do you really need to go any faster?</div><div>= <br></div><div>The recommendation is to apply compression when supported.</= div><div>Some printers do seem to perform better when receiving raster that= is gzipped or deflated as well - many don't seem to care.</div><div>Ho= pefully printers not supporting compression have a large enough buffer to n= ot get starved.</div><div><br></div><div>How large is large - and do you ha= ve any specific problems you are trying to solve?</div><div><br></div></div= ><div>Br,</div><div>Anton</div><div><br></div><div><br></div><div class=3D"= gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">De= n tors 26 feb. 2026 kl 10:41 skrev Holger Gr=C3=A4fe via ipp <<a href=3D= "mailto:[email protected]">[email protected]</a>>:<br></div><blockquote class=3D"gma= il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2= 04,204);padding-left:1ex"><div><div style=3D"font-family:"verdana"= ;;font-size:12px;color:rgb(0,0,0)"><span style=3D"background-color:rgb(255,= 255,255)">Hi Piotr,</span></div> <div style=3D"font-family:"verdana";font-size:12px;color:rgb(0,0,= 0)"><span style=3D"background-color:rgb(255,255,255)">=C2=A0</span></div> <div style=3D"font-family:"verdana";font-size:12px;color:rgb(0,0,= 0)"><span style=3D"background-color:rgb(255,255,255)">you may try whether c= ompression on HTTP level via header field "Content-Encoding" is a= ccepted by the device. There are various compression methods defined, e. g.= "gzip". However, I'm not sure whether any of them is effecti= ve for arbitrary raster image data.</span></div> <div style=3D"font-family:"verdana";font-size:12px;color:rgb(0,0,= 0)"><span style=3D"background-color:rgb(255,255,255)">You can find more det= ails here: <a href=3D"https://developer.mozilla.org/en-US/docs/Web/HTTP/Ref= erence/Headers/Content-Encoding" target=3D"_blank">https://developer.mozill= a.org/en-US/docs/Web/HTTP/Reference/Headers/Content-Encoding</a></span></di= v> <div style=3D"font-family:"verdana";font-size:12px;color:rgb(0,0,= 0)"><span style=3D"background-color:rgb(255,255,255)">=C2=A0</span></div> <div style=3D"font-family:"verdana";font-size:12px;color:rgb(0,0,= 0)">Best regards,</div> <div style=3D"font-family:"verdana";font-size:12px;color:rgb(0,0,= 0)">Holger</div> <div style=3D"font-family:"verdana";font-size:12px;color:rgb(0,0,= 0)">=C2=A0</div> <div id=3D"m_4571212071976011944sub-body-container" style=3D"margin:10px 5p= x 5px 10px;padding:10px 0px 10px 10px;border-left:2px solid rgb(195,217,229= )"> <div style=3D"margin:0px 0px 10px"> <div><b>Gesendet: </b>Donnerstag, 26. Februar 2026 um 04:40</div> <div><b>Von: </b>"Piotr Pawliczek via ipp" <<a href=3D"mailto:= [email protected]" target=3D"_blank">[email protected]</a>></div> <div><b>An: </b>"PWG IPP Workgroup" <<a href=3D"mailto:ipp@pwg= .org" target=3D"_blank">[email protected]</a>></div> <div><b>CC: </b>"Piotr Pawliczek" <<a href=3D"mailto:pawliczek= @google.com" target=3D"_blank">[email protected]</a>></div> <div><b>Betreff: </b>[IPP] Raster compression</div> </div> <div><br> <div>Hello Everyone,</div> <div>=C2=A0</div> <div>I am looking for guidance on the best approach for handling larger ras= ters. Specifically, what is the current recommended method for raster compr= ession?</div> <div>=C2=A0</div> <div>There is a "compression-supported" IPP attribute that allows= the client to apply compression to the IPP payload. However, for many=C2= =A0printers this attribute contains only "none".</div> <div>=C2=A0</div> <div>I cannot find any reference to HTTP-level compression. Is it mentioned= in any IPP document?=C2=A0</div> <div>=C2=A0</div> <div>Or is there any other way to deal with large rasters?</div> <div>=C2=A0</div> <div>I would appreciate any information.</div> <div>=C2=A0</div> <div>Best regards,</div> <div>Piotr</div> </div> _______________________________________________ ipp mailing list <a href=3D= "mailto:[email protected]" target=3D"_blank">[email protected]</a> <a href=3D"https://w= ww.pwg.org/mailman/listinfo/ipp" rel=3D"noopener noreferrer" target=3D"_bla= nk">https://www.pwg.org/mailman/listinfo/ipp</a></div></div> _______________________________________________<br> ipp mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><br> <a href=3D"https://www.pwg.org/mailman/listinfo/ipp" rel=3D"noreferrer" tar= get=3D"_blank">https://www.pwg.org/mailman/listinfo/ipp</a><br> </blockquote></div></div> --00000000000001dd03064bbe2b9d-- --===============8573385877260898573== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ ipp mailing list [email protected] https://www.pwg.org/mailman/listinfo/ipp --===============8573385877260898573==--