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

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

On 9/22/21 7:21 PM, Till Kamppeter wrote:
> I think also the 32 vendor options can be very restrictive, here are some thoughts on what I do and
> what one can do.
> 
> On 23/09/2021 00:47, Robert Krawitz wrote:
>>
>> I understand the concern about embedded platforms, but some printers (in particular, ESC/P2 printers
>> without printer interleave) require substantial host memory to print, particularly at high
>> resolution.  If you're printing at 5760x2880 DPI with an 8-channel printer, that's a lot of memory
>> just to print at all, particularly with a wide page.  Is the purpose of this to limit the memory
>> consumed by PAPPL, or to discourage printing applications that are resource-intensive?
>
> 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.

That's absolutely true, but it's not a reason to restrict all clients.

> My current Gutenprint retro-fit Printer Application would expose 360 dpi for draft, 720 dpi for
> normal, and 1440 dpi for high quality. Clients then would render in these resolutions. Inside the
> Printer Application Gutenprint will dither with any resolution it is capable of, for example with
> 5760x2880 dpi.

It depends upon what you're doing.  Gutenprint does offer quality presets, which vary with the
printer and paper type.  For photos, the ideal output resolution depends upon the printer.  With the
CcMmYKkk printers with 3-4 pl drops, 1440x720 usually does just fine.  With 4 color (or CMYKRB)
printers with 1 pl drops, it needs to be a lot higher, although input resolution doesn't.  If you're
printing extremely detailed line art, though, the higher resolution the better.

> libpappl-retrofit usually reports 3 resolutions for each printer, one for draft, one for normal, and
> one for high quality, selecting the appropriate one when the input data is an image (JPEG, PNG).

But there are more kinds of outputs than that; there are typically about 6-8 quality presets
(economy draft, draft, normal, high, photo, photo high, and best IIRC).

> If the input is PDF or PostScript, the driver uses anything what it needs, not necessarily one of
> the 3 reported resolutions. So sending a line drawing (vector graphics) in PDF and printing in
> highest possible quality, can make Ghostscript render in 5760x2880 for example.

Yep.  But you don't ever want to send higher resolution to the driver than the printing resolution.

> If a PPD file has a "Resolution" option, you can access all the resolutions it offers, on the
> "Printing Defaults" page there will be a "Resolution" entry near the top for the reported
> resolutions, but also a "resolution  entry more down which is set to "automatic-selection". Select
> anything else here to access the advanced resolutions.
> 
> If there is no "Resolution" option in the PPD, resolution is set by some other PPD options
> ("Quality"?). Also this option you find down the list, defaulting to "automatic-selection". Set it
> to something else to get more detailed quality control than only the draft/normal/high of the
> standard IPP attribute.
> 
> The Gutenprint Printer Application itself needs the same high amount of memory and CPU power as the
> CUPS driver.

And there's the rub -- it simply isn't going to run well at high quality settings on low spec
clients.  A router with 256 MB RAM just is not going to be able to print to an Epson R1800 at high
resolution; the RAM is just insufficient.  I doubt whether 32 options or 320 is going to make nearly
as much difference.

>> That certainly isn't something I want to do, for those reasons and more.  But the suggestion of some
>> kind of web application to generate bundles of settings is extremely complicated itself.  I'm not
>> sure what a Gutenprint-specific web UI that allows people to tweak those knobs and create presets
>> would mean, but that would seem to only increase complexity over having just one application.  Where
>> would the web UI back end run?  If it's on the local system, that suggests that a server has to be
>> running there, which makes for its own exposure.  We don't have the resources to support a cloud
>> infrastructure, and it creates additional dependencies (active internet connection that can reach a
>> service) to boot.
> 
> You do not need an extra application. You can add web interface pages to the Printer Application.
> See my PostScript Printer Application. It has one extra page for the system (to upload PPD files)
> and one extra page for the printers ("Device Settings", to configure installable accessories). You
> could add one or more pages for the printers to create presets of advanced adjustments, as I have
> already described with more detail in another e-mail.

Then I don't understand what this "web interface pages" is.

> By the way, I will add two additional interfaces for adding web interface pages to
> libpappl-retrofit, one for extra pages for the system, one for extra pages for the printers.
> 
>    Till