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

[Till K. <til...@gm...>]

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.

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.

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

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.

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.

>> 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.
> 
> As it happens, we get requests for even more options than we already provide, and I've said no to
> some of them.  For example, someone recently wanted a way to remap channels; the black channel on
> his printer was malfunctioning, so he wanted to put that on another channel that he doesn't need.  I
> suggested that he edit the appropriate .xml file.  Some users, like the T-shirt printing crowd,
> really do need a lot of controls to do their printing, and I want to be able to provide those.  If
> that means that users with more conventional printing needs choose to click the Advanced Color
> Settings 4 tab and find it confusing, I consider that acceptable; just don't use those features, and
> we've squirreled them out of the way so that you don't have to see them if you don't want to.
> 
> 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.  And I can state that with fine detail line art
> (such as the 1 degree lines on the old CUPS test page, looks significantly different at 2880x2880
> DPI than at 2880x1440 (which does have additional moire issues) or 1440x1440 DPI on those Epson
> printers with small enough drop sizes that support 2880 DPI in the length dimension.  It does take
> longer to generate and send, but for someone who can use that degree of detail, it matters.  And
> again, an option that someone doesn't need can be ignored; an option that isn't provided can't be done.
> 

See above. Send vector fine art as PDF and Ghostscript Gutenprint use 
the final resolution right away inside the Printer Application.


>>>> What I could do is that in the Snap I could build PAPPL with a higher limit (Snaps bring their own
>>>> libraries).
>>>
>>> That's not good.  This would make it impossible to distribute the printer app via other mechanisms
>>> (e. g. RPM).  I still really wouldn't like to do it, but vendoring PAPPL into Gutenprint and
>>> carrying a patch to eliminate the limits would at least be somewhat portable.  If that broke the
>>> network protocol that wouldn't do, but then a snap would have the same problem.
>>
>> Please don't.  Mini-XML as embedded in Gutenprint is hopelessly out of date, but at least the security exposure is limited.  PAPPL provides network print service and web interfaces and is a much bigger target.
> 
> 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.

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