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

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

All,

> On Sep 21, 2021, at 11:06 AM, Till Kamppeter <til...@gm...> wrote:
> 
> On 21/09/2021 16:22, Robert Krawitz wrote:
>>> PAPPL only allows a fixed (hard-coded) maximum number of vendor-specific options (PAPPL_MAX_VENDOR =
>>> 32) in addition to the standard IPP options for a printer. The number of options in the expert PPD
>>> files is too large for this limit.
>> What??????  Hard-coded limits in this day and age?  I notice that there are a bunch of others.
>> 
> 
> We should report a bug.

Go ahead, but it'll get closed as "wontfix".  Sorry to be so blunt, but PAPPL runs in embedded environments with hard memory limits far below what you'd have on a smartphone, tablet, or desktop/server computer.  Moreover, supporting an arbitrary number of options/values is a path to madness for both the UI designer (that has to deal with unrealistic numbers of options that have to be laid out automatically) and the end user (who has to figure out WTF they all do...)

> Another limit which I observed is that only 4 resolutions can get registered. Also works with practically all drivers except Gutenprint. And for one PPD (Epson Stylus Photo TX810FW - CUPS+Gutenprint v5.3.4 Simplified) I saw also irregularities with the list of paper types, some showing twice and a sub-process of the Printer Application crashing when one changes the paper type. I did not check, but for me it smells like the number of paper types is overrunning the limit here.

PAPPL_MAX_MEDIA is 256.

The number of resolution is limited for two reasons:

1. Apple Raster only supports symmetric resolutions
2. Sending raster data at full device resolution doesn't make sense (generally limit to 720dpi for photos/images and 1440dpi for lines) since big raster data takes a lot longer to send and dithering limits the amount of edge detail that is possible.  So for printers that support 360, 720x360, 720, 1440x720, 1440, 2880x1440, 2880, and 5760x1440dpi should probably only report 360, 720, and 1440 dpi raster data and then upscale as needed.  (I can update PAPPL to support the driver adding printer-resolution-default/-supported values while PAPPL exports the resolution values in the pwg-raster-document-resolution-supported and urf-supported attributes)

> And was Gutenprint not Mike's baby?

a long time ago now...

> The limits not only affect my (interim) retro-fit but also your native Printer Application.
> 
>> With this kind of limit, it would seem very difficult to build a proper RIP using PAPPL.
>>> 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. 
> 
> What do you mean with "vendoring PAPPL into Gutenprint"?

I highly recommend against embedding PAPPL.  The same was done to Mini-XML and the embedded version is hopelessly out of date compared to the current release...

>> If that broke the
>> network protocol that wouldn't do, but then a snap would have the same problem.
> 
> The network protocol cannot break by raising these limits, AFAIK IPP has no limits for the number of attributes and the number of values for each attribute.

Each value is limited to 32767 bytes by the wire protocol, but otherwise this is true in theory.  However, you can cause some pretty serious DoS issues by sending large numbers of values or large numbers of attributes, even on desktop clients.

________________________
Michael Sweet