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

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

On 9/21/21 11:06 AM, Till Kamppeter 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.
> 
> 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?

Mike wrote the original Print plugin for GIMP which I took and started the Gimp-Print (renamed
Gutenprint with release 5.0) project around.  Mike wrote the original CUPS driver for Gutenprint
working with the rest of the team.

> The limits not only affect my (interim) retro-fit but also your native Printer Application.

Yes.  That's a problem.

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

Putting a copy of PAPPL into the Gutenprint source with these limits lifted.  Same kind of thing
that a lot of projects have done with dcraw.

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