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

[Michael S. <ms...@ms...>]

Robert,

> On Sep 22, 2021, at 6:47 PM, Robert Krawitz <rl...@al...> wrote:
>> ...
>> The limits were explicitly chosen as a balance of capability vs. scaling, specifically for a "proper RIP" that might run on an embedded platform without swap/unlimited memory.
> 
> 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?

No, but having fixed limits does make memory usage *predictable*.

>> See my other message to Till, but in the case of resolution we have two sets of values - raster data that is sent to the "RIP" and raster data that is generated by the RIP for the printer.  As for the number of driver/RIP options, the point of IPP Everywhere is to enable printing from all kinds of clients, many of which don't have limited display/memory/CPU resources so we want to have presets/basic capabilities provided by all printers, with the expert stuff available but not required.  PAPPL_MAX_VENDOR is 32, which *should* be enough for a native Gutenprint implementation (the PPD implementation doubles up many of the current settings).
> 
> It's not enough for a full featured Gutenprint implementation; some printers (particularly Epson
> printers) have a lot of obscure options that we want to make available for people who need them.
> That doesn't mean they all have to be on one page.  With both the CUPS driver and GIMP plugin we
> provide multiple pages with successive disclosure of complexity, as a former colleague describe it.

Understand that how Gutenprint exposes options in PPD files isn't how it has to expose them over IPP.  More specifically, IPP has collection attributes (think of them as dictionaries) that cam contain any number of (typically related) member attributes. So just because you need to have 30 PPD options to describe transfer curves doesn't mean that you have to have 30 IPP attributes.  Group the options in IPP collections, and include a member attribute for named presets for these collections - that supports stock and custom "easy" settings as well as complete control over a particular category of options.

(honestly you could put everything in a single collection, but I don't think that is actually a good idea)

> ...
> On the subject of resolutions, many Epson printers use different ink size drop sets for 360,
> 720x360, and 720 DPI, so the results will be significantly different.  Speaking for myself, at any
> rate, I want to provide this flexibility to users.

Nothing prevents you from supporting all resolutions.  But modern Clients can typically only rasterize at 1:1 resolutions (certainly this is the case for all AirPrint clients), and Windows' Mopria class driver only supports a small number of resolutions they decide are OK - 300, 360, 600, and 720 dpi right now. (not even the super-common 203dpi of label and some dye-sub printers...)

My point is simply that printing resolution != rasterization resolution.  And yes you could report 2880x2880 DPI with the current PAPPL, no problem, but you'll need to upsample to 5760x2880 DPI if that is the printing resolution a user chooses, being fully prepared to do so from 360 dpi if that is what the Client sends you.

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

You already have a GTK+ UI, and modern web UI has similar capabilities.

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

I'm not sure I understand what you're saying?

> Where
> would the web UI back end run?

It is part of the printer application.  IPP runs over HTTP.  And a web interface is a required part of AirPrint, Mopria, and IPP Everywhere.

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

There is no need for cloud crap.  This is a local application.  Typically only listening on localhost (unless you configure it to share on the local network), and PAPPL is taking care of 99% of the security issues for you. (the other 1% depends on what kind of extra web UI you provide, but for Gutenprint I don't see there being anything that PAPPL doesn't already handle for you...)

________________________
Michael Sweet