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

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

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.

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.

And was Gutenprint not Mike's baby?

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

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

    Till