tillkamppeter
commented
7 months ago The intention is that one can test the Printer Application if one does not have a (physical hardware) printer which is supported by it.
The way how it is implemented in this PR is not so good and partially wrong:
- It is not that flexible when the test queue is there when there are no other queues and not there when there are already queues.
- The test queues in this PR has a hard-coded driver and this driver is of the HPLIP Printer Application. We are adding a feature to PAPPL though, and therefore it needs to work with any Printer Application.
- The driver must be selectable to be able to debug any driver
- It must be possible to print through the test queue and investigate the result. So we need a backend (device) which prints into a file.
What one needs for that is an additional backend (device) which prints into a file (destination file name/path automatic to avoid extra UI). We let this backend only appear in the devices list on the "Add printer" screen of the web interface when we are in debug logging mode, so that it does not clutter the interface for normal use. When the user selects it they are supposed to select the driver manually, to be able to debug any driver. It should also be possible to create a print queue with it via the command line interface.
michaelrsweet
Now, these changes allow user to create printer job queue without creating a printer when log level is debug. Through these changes, a test-printer will be created and will be stored with system. Whenever user changes the log level to debug and he have not created any printer yet, then the test-printer will be visible to him using which, they can create a printer queue without adding a printer until log level is debug. This test-printer is not being added in main printer array which will be created by user in future and this is being ensure using a variable "check_add_printer".