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

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

Robert,

> On Sep 21, 2021, at 10:22 AM, Robert Krawitz <rl...@al...> wrote:
> 
> On 9/21/21 10:01 AM, Till Kamppeter wrote:
>> On 21/09/2021 02:28, Robert Krawitz wrote:
>>>> Note that the retro-fit is not perfect, especially due to the restricted number of vendor-specific
>>>> options in PAPPL I could base my Printer Application only on the simplified PPDs and not on the
>>>> expert ones.
>>> 
>>> What restriction is this?
>> 
>> 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.
> 
> With this kind of limit, it would seem very difficult to build a proper RIP using PAPPL.

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.

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

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

________________________
Michael Sweet