I've committed some changes to Gpr to CVS. The most
significant ones involve "tab categories" for the
GUI. Previously, Gpr displayed three tabs: "Main",
"Common Options", and "Printer Options".
Some PPD files contain a plethora of options, most
of which ended up in the "Printer Options" tab. I've
added the ability to move groups of options to their
own tabs, using an XML-based file to define tab
[Sidenote: Yes, PPD has the ability to define
option groupings, but it appears that few people use
them. Thomas Hubbell has code in Gpr that identifies
these options and displays them along with the other
printer options. I didn't think it was practical to
go back and modify a bunch of PPD files, so I've
taken this alternate route instead. The two
approaches are not mutually exclusive.]
The XML "tab category" file should be installed as
/usr/share/gpr/tabs/categories.xml. A sample on is
<gprtab:StringMatch text="Watermark Font"/>
This sample file defines one new tab category, "Watermark".
As options are processed by Gpr, they are compared to
existing patterns defined in the XML file. Patterns
can take two forms:
PatternMatch specifies a regular expression string. Any
PPD option description matching the regexp will be displayed
in the matching tab, instead of the default "Printer" tab.
StringMatch specifies an exact string match. In the example
above, the StringMatch, "Watermark Font", could actually
be omitted, because this string would already be matched
by the previous regular expression. StringMatches are
computationally cheaper, and should be preferred when
option spellings within a tab group are diverse.
In the absence of a categories.xml file, Gpr should
function normally. You just won't see any extra tabs.
I'm considering modifying the scheme slightly to allow
multiple .xml files in /usr/share/gpr. This might make
it easier to add tabs categories. The coding effort
would be small.
I know of at least one bug in the code (though it's doubtful
it would be exercised in normal use). The number of unknown
bugs is n, where n is a value between 0 and m.
Note that I've tested this against libxml versions 1.4.0 and
1.8.12. Please post any problems here or on the bug list
on Source Forge.