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

[Robert K. <rl...@al...>]

On 9/22/21 9:11 PM, Solomon Peachy wrote:
> 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.

Actually, the wide format printers (17"+) are less of a problem -- they all do weaving
(interleaving) inside the printer, and all we need is enough buffering for one row of each color.
The most demanding ones are the high resolution prosumer printers, a step below the pro ones, where
there needs to be enough buffering for a lot of rows, where "lot of" depends on the printer
resolution in more ways than one would realize.  Particularly bad are things like the R1800 (which
is why I used that as an example) where it's really necessary to print at very high resolution to
get decent photo output, because there are no light inks to generate smooth tones with larger drop
sizes.

> (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)

A lot of routers have less RAM than the Raspberry Pi 0, and RAM's more of an issue than CPU.  And I
could see someone wanting to run a printer app there, if they're using it as a print server.  But
they wouldn't be able to do anything very sophisticated, and that's not what I think we should be
targeting.

> 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.

Yes, and as far as that goes I think input resolution and printing resolution should be decoupled,
as long as the input resolution is not allowed to exceed the output resolution.  But some people
need that very high input resolution.

> 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.

Interestingly, in the office (where I was last >18 months ago) we had some high end ImageRunner
printers that someone was trying to print a large PDF file on it and the thing choked; it basically
got hung up forever trying to render the PDF.  That was right around the time I finally got color
PCL printing working (and was sort of the impetus for it).  Our PCL driver is pretty
unsophisticated; it's raster-only, but it worked fine and I printed the person's PDF for him.  He
was suitably impressed.

> 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.

I agree.  We do get a fair number of questions from people who are desperate to hook up their old
printers to a modern Mac, where the vendor doesn't support any Mac OS beyond 10.6 or so and never
will.  But we also get plenty of tickets from people who want to do interesting things with it,
sometimes things that can't be done with the OEM drivers, because those drivers are designed to
support OEM inks and papers (which is where the OEMs make their real money) and can't do things like
white underlay coats and truly absurd quantities of third party inks that are necessary to
successfully print to T-shirts and the like.

I don't mind having good defaults and making the app easy to use for end users who want to do basic
things, but I draw the line -- hard -- at dumbing down the app because somebody /might/ stumble
across something obscure and get themselves in trouble.  Particularly given how many printers are
supposed to be IPP printers these days (although I don't know that the typical cheap home printers
are yet), I'd rather target 1,200 people who want to do something interesting than 1,200,000 or
120,000,000 people who don't really need Gutenprint because they're running on OEM-supported
printers and doing just fine (bonus points if you know the reference!)

> 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.

Aye, there's the bottom line.  If PAPPL restrictions don't allow us to properly meet the needs of
our user base, then that's just not an option for us.  I desperately want to get away from PPD
files; I've never cared for them and I've been ranting off and on about the subject for 20 years
now.  But replacing them with something that's actually a lot less capable is a non-starter.  We'd
be better off basing it on libgutenprintui2 and properly CUPS-enabling that.