Turning the PostScript Printer Application into the retro-fit library #8
Replies: 7 comments
-
Here is a new one: With this one and the newest GIT master state of cups-filters the PPD attributes For special needs not covered one only needs to switch the special options away from "automatic-selection" to manually fine-tune. Do not forget to get back to "automatic-selection" when done with the special job. Tested with following PPD files: HPLIP ("hpcups" driver), Gutenprint, Foomatic ("bjc250gs" and "hl7x0" drivers), PostScript PPDs from Ricoh, Toshiba, HP. |
Beta Was this translation helpful? Give feedback.
-
Next milestone: This one and again the newest snapshot of the cups-filters GIT master as of today has now a new handling of handling print resolutions. The "Resolution" option of the PPD is now handled as part of the auto-generation of option presets for print-color-mode, print-quality, and print-content-optimize and the resolutions for PAPPL's list of supported resolutions are the ones resulting from setting the PPD options from the presets in the three print qualities "draft", "normal", and "high" This is done because PAPPL does not apply the default resolution to the jobs but takes the first of its resolution entries for "draft", the last for "high" and one in the middle for "normal" quality. This way the correct resolutions get to the correct places so that each of the three print qualities is always done with the corresponding resolution. To allow to manually set a different resolution (at least for PDF and PostScript input), even if the PPD's "Resolution" option has more than the maximum of the 4 choices allowed by PAPPL, "Resolution" is also taken as a vendor option and this way the full amount of choices gets available in the web interface. If the added "automatic-selection" entry is selected, the above mentioned mechanism sets the correct resolution automatically. Note that in rare cases there can be 2 resolutions where the lower one appears twice in the drop down of the web interface. This is a workaround to make PAPPL choose the lower resolution for normal quality. |
Beta Was this translation helpful? Give feedback.
-
Another milestone: This one allows to use a chain of any number of filter functions, both in the conversions for spooling printing mode and also in the formats for streaming printing mode. This way we especially add the In streaming printing mode (input is PWG/Apple Raster or an image) we instruct the filters to stream the job data and not load the whole jobs into a temporary file or into memory only to check which format it is and whether it perhaps does not contain any page for printing. For that we supply the boolean option |
Beta Was this translation helpful? Give feedback.
-
And here is another milestone: Now we are adding the last major feature for the CUPS driver retro-fitting framework: Support for CUPS backends Several classic CUPS drivers do not only consist of PPDs and filters but also bring a CUPS backend, or several of them. HPLIP provides one to talk with USB printers in IEEE-1284 packet mode, protocol 3, 7/1/3. By the way, protocol 1 is uni-directional stream, protocol 2 bi-directional stream (both supported by PAPPL's own USB scheme and the To be able to correctly retro-fit this into a Printer Application I have now added a custom PAPPL scheme, named "cups" to which a backend directory and include/exclude lists for backends in that directory can get assigned. This scheme integrates the backends in the Printer Application listing all devices which the backends discover (when all run in turn without arguments, like This is not complete yet. It is an interim snapshot. it only lists the devices (so you see them in the "Device:" list of the "Add Printer" web interface page, but when adding a printer using such a device, it will not print, as the communication for job execution is not implemented yet. You only can see that the devices got correctly discovered from withing the Printer Application. If you actually want to print you have to select one of PAPPL's own devices. I have also implemented the back channel and side channel concepts of CUPS' filters and backends, so that classic drivers which use them, will correctly work, and also some functionality of PAPPL's device concept will work better then. Some of the implementation is in cups-filters (especially in the To test, point the The implementation for actual job processing will come soon. |
Beta Was this translation helpful? Give feedback.
-
In this snapshot So now you can also select printers based on CUPS backends when you add a new printer and the printer will actually print, and printing works as before: You select the media which you have in your trays on the "Media" web interface page, then you selext your option defaults on "Printing defaults". And if you have a PostScript printer, you can, as before, poll the installable accessory configuration and option defaults from the printer (if it supports it), on the "Device Settings" page. So nothing has changed in operation. You can also print easily using the "print-color-mode", "print-quality", and "print-content-optimize" attributes/options in the web in terface/on your client/on your phone and easily control any printer with standard operations, as before. In most cases nothing will change for you when using a CUPS backend, but there are several printers out there which will perhaps not run with PAPPL's built-in backends or not perform well without the manufacturer's specialized backend. But note: CUPS backends are not always better: HPLIP comes with its own But I have found a shortcoming in HPLIP's The backends which come with CUPS have back and side channels, and so you can poll PostScript printers through them. Note also that sometimes device discovery and job execution are not done by the same backend. In addition, while testing polling option defaults I have seen a little issue: Some of the PPD's options are controlled by the presets (the "print-color-mode", "print-quality", and "print-content-optimize" attributes/options). In the web interface (on the "printing defaults" page) they appear with "automatic-selection" as default setting. It can happen that one or another of these options is queryiable, so polling defaults gets a default value fro such an option from the printer and sets it locally in the Printer Application. What happened was that the option got moved away from "auto-selection" to the printer's default as forced, manual default, overriding the presets. This is ugly. You do not see it on "Device Settings" and on "Printing Defaults" you easily overlook it. To improve on this I do not let default settings queried from the printer move an option away from "automatic-selection" into manual mode, but instead, I search for the setting in the presets and change the presets yo the ones with best match all the queried defaults and if two match equally well I select the one which changes the least amount of the current defaults. This means, that for example if you have set a default on your printer (via its web interface) for grayscale, the p[olling of option defaults will switch "print-color-mode" to grayscale (you will see "B&W" selected under "Print Mode" on the "Printing Defaults" page). If you set your printer's default resolution from 600 dpi to 1200 dpi, the polling of your printer's defaults will result in your "print-quality"setting in the Printer Application being switched to "High", ... Now you will wonder why the printer manufacturers do select the pollable options so oddly and do not have "print-color-mode", "print-quality", and "print-content-optimize" as pollable options. This is because the presets do not come from the manufacturers, the presets (the selection of which options they control) are generated by an algorithm which I have created and implemented in cups-filters (see post more above here). Now the major functionality is there. Only smaller pieces to come ... |
Beta Was this translation helpful? Give feedback.
-
Another snapshot: Now I have re-structured the backend support, so that the backend is actually running in PAPPL's device framework, but sharing the This did not only make the code somewhat cleaner but also the switchover made me discover some bugs and so the whole program is more stable, especially on querying default option settings from PostScript printers ("Device Settings" in web intwrface), where sometimes the web interface did not display the page with the results. The function to identify the printer (get printer making noise and lighting up its display without printing anything, to find the printer in a group of printers) got also some improvemens: It is checked by the device ID of the printer (not by the selected driver) whether the printer understands PostScript, and if so, a zero-page PostScript job gets sent to the printer, otherwise we request status and device ID via PAPPLs device API functions (calling callbacks of the device) and we also send a side channel command to make the CUPS backends trigger a soft reset on the printer. Not everything is supported by every printer or every PAPPL or CUPS backend, so YMMV whether the "Identify Printer" button makes the printer actually do something. But if you create a Printer Application with this framework, you can simply replace the identify function by your own one. Any hints for other identification methods are welcome. |
Beta Was this translation helpful? Give feedback.
-
I have finally turned this project into an easy-to-use library now! You find it here on the OpenPrinting GitHub, the pappl-retrofit project! So there will be no further sneak previews and write-ups in this thread. Instead there will be commits with my thoughts, ideas, and implementation details in the commit messages, as I already do with the CUPS Snap and also here with the PostScript Printer Application. There will be first retro-fitted drivers here on the OpenPrinting GitHub and in the Snap Store soon! |
Beta Was this translation helpful? Give feedback.
-
I am currently working on a framework/library to easily retro-fit classic CUPS printer drivers into PAPPL-based Printer Applications. For this I have started to make the functions out of which the PostScript Printer Application is composed "library-ready", getting rid of global variables, generalising them for all types of printers and drivers, ...
The code is in this file:
ps-printer-app.c.txt
To try it out, simply take the GIT master of the PostScript Printer Application (this project) and replace its
ps-printer-app.c
by this file. Then build the Snap (or build classically with newest snapshots of cups-filters and PAPPL) as described inREADME.md
. As a result you should get the PostScript Printer Application with its usual features, probably indistinguishable from the original, but with the new innards. And this will also be the future of it, once the library is started as a new GitHub repo here at OpenPrinting.Beta Was this translation helpful? Give feedback.
All reactions