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

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

On 9/22/21 9:51 PM, Michael Sweet wrote:
> Robert,
> 
>> On Sep 22, 2021, at 6:47 PM, Robert Krawitz <rl...@al... <mailto: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*.

Well, other than that the underlying driver might not have such predictable memory usage.

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

So I could have one set of options for the density settings and so forth, and I'm limited to 30 sets
of options (or one set of options for each group of options, such as Basic Printer Options, Basic
Color Options, Advanced Color Options 1, and so forth)?  Because that's not what it looked like.

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

Which is perfectly acceptable.

>> 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'd just as soon use the existing GTK+ UI rather than have to write a new web application.

Even a local TCP port (http or https://localhost) has its problems, since it means that something
running under a different UID can access it.  A lot of browsers strongly discourage use of http
these days, and https means getting a certificate.  Just a whole lot of hoops to jump through for
what looks to me to be dubious benefit.

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

I don't understand what the architecture would look like.  What exactly would this web UI do?  Where
would the back end run?  The printing application is a normal binary, presenting a UI.  A web
application means a server somewhere.  Why should there be a web UI in addition to the printing
application UI?

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

It sounds like this would be separate from the main UI.\