Re: [Foomatic] Printer driver UI [proposal]

[Johannes Meixner <jsmeix suse de>]

Hello,

On Mar 13 14:44 Michael Goffioul wrote (shortened):
> Basically, the main motivation of this mail is the fact that printer
> driver are getting still more complex (like gimp-print) and that
> presenting driver options to the user in a usual hierarchical way
> (like in a tree view as in KDEPrint) becomes very unfriendly and
> confusing when you have a lot of options.

According to my understanding the options in a PPD file cannot be
ordered tree baseed but they are a totally flat list.
But what can be ordered tree baseed according to the PPD specification
are so called option groups.
I.e. you can group the flat list of options into a tree baseed
structure of option groups and nested sub-groups.
This way the user gets a hierarchical selection tree with the
most often used options on top.
It is similar to the directories in Unix which make a
hierarchical tree structure over the flat list of inodes.

> Many of those driver options will probably never be used by a
> normal user so it's not needed to show them in all cases.

Then hide them in a low level option group or in a sub-group.

See how Till it has made for the *PrintoutMode option for Foomatic 3.x

But the *PrintoutMode option does much more!

It is a meta-option where one selection of a particular PrintoutMode
sets several member options which are necessary for this PrintoutMode.
For example to switch the gimpprint driver from PrintoutMode Draft.Gray
to PrintoutMode Photo needs several gimpprint driver parameter
settings. All necessary gimpprint driver parameter settings are
done automatically by selecting one PrintoutMode. This is done
by the famous Foomatic 3.x "foomatic-rip" filter.
Till, who made this perfect solution, can explain it much better than me.

I think that the Foomatic 3.x *PrintoutMode option already solved
the whole problem.


> IMO it could be much better for the user if we could define a framework
> that could be used to describe how the driver settings should be
> presented to the user.

The framework exists:
Option groups and nested sub-groups according to the PPD specification.


> Some kind of metadata contained in the printer driver
...
> - UI can be described using XML syntax, and embedded in the driver
>   file (for example, PPD file) using comments. These metadata can

I totally disagree to introduce any kind of special data
which is not in full compliance to the PPD specification.

If you need data it must be in the PPD file and not in the
printer driver because only the PPD file is accessible via
the CUPS server using
  http://server.domain:631/printers/destination.ppd
but the driver is normally unaccessible over a network.

If you need data it must be in the PPD file in a 100% compliant
way to the PPD specification.
This is no problem as you can introduce as many main keywords
and option keywords as you like.
If there is no *OpenUI/*CloseUI the option would never be
shown tho the user - for example the *ImageableArea and
*PaperDimension options but any application program can read
them nevertheless by getting the whole PPD file from the
cups server.

For example the PPD specification reads that the *Resolution
main keyword can only have the following kind of option keywords
either of the form [0-9]*dpi or [0-9]*x[0-9]*dpi or "Unknown".
This makes sure an application program can read the possible
resolutions of the printer.

I made a proposal how this may work for OpenOffice.
I will forward the mail soon.


Regards,
Johannes Meixner
-----------------------------------------------------------
SuSE Linux AG, Deutschherrnstr. 15-19  Mail: jsmeix suse de
D-90429 Nuernberg, Germany         WWW: http://www.suse.de/
-----------------------------------------------------------