With an old "printtool" it was possible to add through its interface
additional Ghostscript options as needed. With the current setup
not only this is gone but the whole setup will be clobbered every
time one is doing changes on any other, unrelated, printer queue.
The problem is that, for example, at least for some colour inkjets
one has to run alignment tests and adjust alignment values accordingly,
as extra options to ghostsctript, after _every_ cartridge change.
These things cannot be included in a "standard" printer database as
they depend on minutae of a geometry of a newly aquired cartridge.
I will continue to think about this, but it is hard.
There is no simple way to expose if the filtration is using ghostscript, so it
is not trivial to pass this through. The best answer is to teach the backend at:
about these options.
If you wish to hack the backend for your printer, you can add options to the
foomatic file that specifies the printer (the real one, in
/usr/share/printconf/foomatic/data ) and you would then be able to edit the
options in printconf.
This is an evolving problem, I will continue to work on it.
If all else fails, continue using printtool and rhs-printfilters for now.
I am afraid that hacking backend is not a very good proposition as the situation
is dynamic. This is, of course, possible but hardly a good answer for
an average user. An extra, optional, configuration file in a spool directory
which is read by a filter and where one can type whatever via 'printconfig'
interface, exactly as it was done before, seems like a good idea.
I have not a clue what other options one could want to put there but with
so many diverse drivers for ghostscript is quite likely that there will
be other uses. :-)
I have to trust the linux printing database, as all the brain trust is
developing there. This will not be changed.