Bug 35473 - missing "ExtraGSoptions" functionality
Summary: missing "ExtraGSoptions" functionality
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: printconf   
(Show other bugs)
Version: 7.1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Crutcher Dunnavant
QA Contact: David Lawrence
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2001-04-10 16:48 UTC by Michal Jaegermann
Modified: 2007-04-18 16:32 UTC (History)
0 users

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-04-12 00:18:18 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Michal Jaegermann 2001-04-10 16:48:11 UTC
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.


Comment 1 Crutcher Dunnavant 2001-04-12 00:03:37 UTC
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.

Comment 2 Michal Jaegermann 2001-04-12 00:18:14 UTC
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. :-)

Comment 3 Crutcher Dunnavant 2001-08-28 04:38:05 UTC
I have to trust the linux printing database, as all the brain trust is
developing there. This will not be changed.

Note You need to log in before you can comment on or make changes to this bug.