Add human-readable strings and data pointers to the driver's vendor options/attributes

[tillkamppeter]

Is your feature request related to a problem? Please describe.
When adding vendor-specific attributes to a driver you specify an option name and in case of a keyword-type attribute the choice keywords. All these are in IPP keyword syntax. In the web interface they look rather ugly. See this screenshot of the sample Printer Application of PAPPL:

In the PostScript Printer Application I will derive these options from PPD files and I want to have thes strings from the PPD file appear here.

Describe the solution you'd like
In addition to the list of vendor options in the driver data structure and the driver IPP attributes carrying the full definition of the option there should be ideally:

• A data structure to hold human-readable strings for all option names and also for all choice names of enumerated choice/keyword options
• Data pointers for each option=choice pair of enumerated choice/keyword options, one for "true" and one for "false" for each boolean option and one for each numeric or string option.

The above-mentioned extra data structures would get filled in the print queue/driver setup phase (ps_callback() in ps-printer-app). In case of the PostScript Printer Application, after reading the PPD file and populating the standard fields of the driver data structure the PPD options uncovered by the this structure would be added as vendor options. The human-readable strings would be taken from the "OpenUI...CloseUI" structures in the PPD, the so-called "Translation Values", the strings after the /, for both options and choices. The data pointers of each setting in my case would point to a data structure of two strings, one being the (machine-readable) option name and one the (machine-readable) choice name of the PPD. For numeric and string options there will be only one data pointer, pointing to a pair of the option name and a choice name template, containing %s or %d where the string or the number gets inserted. On job execution the data pointer of each selected setting will get read out and added to the option list to be supplied to the filters/marked in the PPD data structure.

If this is too complex for gemeral use in PAPPL I would like to have at least one freely usable data pointer in the pappl_pr_driver_data_t data structure, so that I can let it point to my own data structure which will hold the above-mentioned information for the PostScript Printer Application.

Describe alternatives you've considered
At least one freely usable data pointer in the pappl_pr_driver_data_t data structure and a facility for human-readable strings in the web interface.

[michaelrsweet]

@tillkamppeter This is what strings files are for. Once you add resources for them (where they map the keywords used for attribute names and values to human-readable strings), the client will be able to grab them and use them to lookup the strings to display.

I think the only thing that remains for this is to provide a way to explicitly specify which strings files go with which printer - right now it is one set of strings files for all printers.

[tillkamppeter]

Some questions:

• Are these strings files actual files or can they also simply be data structures within a Printer Application?
• Can such a strings file be generated when creating a printer, for example in the driver callback function (ps_callback() in the PS Printer Application) I would read the PPD and generate the vendor attributes and its strings from the PPD?
• They should be separate, per-printer

Do we need a separate, new Issue for this?

[tillkamppeter]

Another question:
If a strings file is defined, will the web interface use it to display the vendor options?
Could you add an example to the sample Printer Application of PAPPL?

[michaelrsweet]

@tillkamppeter See the documentation for papplSystemAddStringsFile and papplSystemAddStringsData. Strings files can be actual files or in-memory strings that represent the contents of the files. For efficiency's sake I would actually generate files on disk containing the cached localization data.

The strings files can be created at any time, but as I noted the current architecture is based around a single set of shared localization files. And in fact it should be trivial for you to generate a single set of strings files from all of the PPDs that you bundle with your PostScript printer application.

Adding support for per-printer localization files is certainly possible, however I will note that NO existing IPP clients support arbitrary IPP attributes (so none of the vendor attributes you are exposing will be visible), and the only things that get localized are vendor-specific media types and sources at present. All other localization data comes directly from CUPS.

Adding support for localizing the web interface is issue #58 which is part of my 1.1 milestone. Feel free to add a request for per-printer localization files, but that won't be in v1.0.

[tillkamppeter]

The human-readable strings are only needed for the representation of the vendor attributes in the web interface.

Pre-generation of the strings for all PPDs (~4000 currently) will make the build of the Snap take very long and also produce a huge Snap package. Therefore my idea is that when a printer is created (or when the Printer Application with created printer starts) the driver callback which anyway reads the PPD to populate the driver data also, when creating the driver attributes for the vendor options also extract the human-readable strings from the PPD and add them to an in-memory strings file (papplSystemAddStringsData?) where they live while the Printer Application is running. Would the web interface then use them?

[michaelrsweet]

@tillkamppeter First, you'd be surprised how small the combined message catalog could be - there is a LOT of duplication.

Second, issue #58 (which covers the localization of the web interface) is not yet implemented and won't be until v1.1.