Re: [Gimp-print-devel] Gutenprint Printer Application (Native)

[Solomon P. <pi...@sh...>]

On Thu, Sep 23, 2021 at 01:21:21AM +0200, Till Kamppeter wrote:
> As I understand, the limitations are also done with clients in mind. If you
> have a low-resource client, and your Printer Application reports a 5760x2880
> dpi resolution for PWG Raster input, the client could have problems
> rendering this.

Let's be clear here, even a $5 Raspberry Pi Zero has sufficient 
resources (RAM and CPU oomph) to RIP all but the most specialized (eg 
max resolution wide format banner printing) output on Epson devices.

(And when you're spending >$20K on such a printer, it's reasonable to 
 expect that the system it's plugged into is more capable than a RPi Zero)

That said, "printer hardware resolution" and "input data resolution" are 
only loosely coupled and their relation depends entirely on what you're 
trying to print/produce.

A printer may have a raw hardware resolution of 5760x2800, and you would 
want to use every bit of that when printing containing fine line details 
but very little color variation.  Whereas for a photograph, continuous 
color tones matter more than fine detail, and the necessity of dithering 
reduces the usable "image" resolution to a fraction of the hardware 
resolution.  Even with that 5760x2880 hardware resolution there's 
probably little point in supplying an photograph that's much over 
300dpi.

Ultimately the question is "what is Gutenprint used for" -- if it's just 
"enable folks use their ancient pre-IPP printer to print office 
documents and grand-cat photos" then what you've implemented today with 
the simplified PPDs is fine -- and a "native" version would presumably 
face the same sorts of restrictions, at least if we're to use stock 
upstream PAPPL as its base.

However, I strongly believe that today the majority of the Gutenprint 
userbase are folks with specialized needs, using Gutenprint as a highly 
capable RIP that happens to be a CUPS driver.  What they care about is 
accessible functionality; take that away (or make it substantially 
harder to use) they might as well just go back to using official 
manufacturer SDKs under Windows.

Don't get me wrong, there are some substantial benefits from the 
integrated printer application approach vs the loosely-coupled set of 
filters but at the end of the day we need to meet our users' needs.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (libra.chat)