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

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

On 21/09/2021 17:38, Michael Sweet via Gimp-print-devel wrote:
> 
> 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...)
>

OK, it would be a pain to scroll through that many options (in one long 
list) on a phone ...

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

The problem with the paper types is that the ppd-cache.c functions 
(these are the same in libcups and libppd) assign the same PWG name to 
different PPD names of some paper types (variations of glossy photo 
paper). I have now simply skipped the duplicates.

> 
> PAPPL_MAX_MEDIA is 256.
>

These are the paper sizes, no problem with them.

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

I have now added a limitation for the PAPPL-reported input resolutions 
in libpappl-retrofit: 360 dpi for draft, 720 dpi for normal, and 1440 
dpi for high print quality. Internally, the resolutions of APPL/PWG 
Raster input are converted to whatever the driver needs. PDF and 
PostScript input is directly rendered in the resolution which the driver 
requests.

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

I am also against this practice, it is a nightmare for packaging and 
security fix handling.

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

OK.

    Till