From: Thomas H. <thu...@co...> - 2001-03-15 17:37:36
|
Mark Pruett wrote: > > Thomas Hubbell wrote: > > > > A Mennucc1 wrote: > > > so , I would propose to change the names of the tabs > > > common options -> filter options > > > advanced options -> printer options > > > > I'm not so sure I would want to use "filter options" because an > > inexperienced user may not understand what this means. How about the > > following: > > > > common options -> GPr options > > advanced options -> printer options > > > > Using "GPr Options" instead of common options is not *exactly* true, > > since these options are really implemented in libppd. But, I think it > > would signify to the user that these options are specific to GPr, not > > the printer. Comments? > > I never found "common options" particularly confusing, > but I agree that "filter options" may not be clear to > many users (it requires some understanding of what goes > on "under the hood"). Perhaps "Standard Options"? I never found "common options" very confusing, either. But, then again, I knew what I meant when I created the label, so I may not be completely objective! "Standard Options" is valid, but I don't see that it has any particular advantage over "Common Options" in terms of clarity. I'm for sticking with what we have, unless someone can think of something that would *really* make a significant difference in clarity. > > I guess what is needed is a way to hide the gpr options if they are > > found in the ppd. > > > > This could be problematic, though. It is easy to look for specific > > strings like "n-up" and "collate", but these features are often called > > by different names. HP uses the name HPnup to describe its nup feature > > (the company prefix, "HP", is actually the recommended way of naming > > non-standard ppd entries in the PPD spec, iirc). So, we could always > > take a guess by prepending the company prefix (these are listed in the > > ppd spec) to the specific entry we wish to include. Given the rather > > loose compliance to the ppd standard of some vendors, we probably won't > > catch them all. I think we could get sufficiently close, though. > > I don't think the occasional collision between a PPD > option and a libppd option is a big enough problem > to worry over. You are probably correct. I think it will be a rare occurrance anyway. > I do have a suggestion for dealing with all the options > that currently show up in the more feature-rich printers. > > There's been discussion of grouping the PPD options > into functional groups (e.g. Paper Handling, Watermarks). > In a perfect world the vendors would have done this > within the PPDs (I've been told that PPD syntax allows > for this), but in practice I've not seen it. Me neither. That's really why it wasn't implemented from the beginning! > I propose that we add a facility within GPr to handle > this in an ad hoc way. GPr could read a text file > (probably XML) that defined these ad hoc groups. Here's > an example of what I mean: > > <group name="Watermarks"> > <pattern text="Watermark Intensity"> > <pattern text="Watermark Font"> > <pattern text="Watermark Size*"> > <pattern text="Print Watermark"> > <pattern text="Watermark Pages"> > <pattern text="Watermark Text"> > <pattern text="Watermark"> > <pattern text="Watermark Angle"> > <pattern text="Watermark Color"> > <pattern text="Watermark Style"> > <pattern text="*[Ww]atermark*"> > </group> > > As the UI was created, if an option matched > a pattern, within a group, it would be placed > on that group's tab. Otherwise, it would be > placed on the "Advanced" tab (which might more > aptly be named "Other" or "Miscellaneous"). I had considered something very similar to this awhile back (XML and everything!), but I never had the bandwidth to address it. I think this is a good idea. It does require that we add a decent amount of logic to the existing code base, but I think it will increase the flexibility immensely. When I was considering this, I had also thought of something in line with my customization idea. There could be a default file as described above to parse the PPD into the proper tabs. Instead of re-parsing the PPD everytime GPr is loaded, the option-to-tab groupings could be cached in a text file. GPr would then consult this cached file to create the UI in the future. If a ppd maker/vendor were so inclined, they could offer a customized version of this "cached" description file. Then they could specify exactly how many tabs, their names, and the items that belong on the tabs. If we spiced up the UI a bit (put appropriate icons on the various tabs that we created), the customized file could offer alternate images as well. This may be a bit "too much" for a simple printing utility (and may rarely be utilized!), but I don't think it would require much more effort if we have the basic parsing/caching code intact. > What I'm trying to avoid is munging with PPD > files. We should do our best to work with existing > PPD files and their capabilities. That's a valid point. We may be able to influence what goes into the HP ppds and we might be able to convince Grant Taylor to add this to the ppds his software generates, but what about the rest of ppds out there? It's much easier to alter gpr than to munge the scores of ppds in existence to work with our system. -- Thomas Hubbell CompuMetric Labs, Inc. thu...@co... |