|
From: Robert K. <rl...@al...> - 2021-09-21 14:22:40
|
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. > 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. |