Re: [Foomatic] Printer driver UI [proposal]

[David Chappell <David Chappell trincoll edu>]

On Thu, 2003-03-13 at 10:48, Johannes Meixner wrote:
> 
> Hello,
> 
> On Mar 13 16:21 Michael Goffioul wrote (shortened):
> > http://www.geocities.com/kdeprint/slide_1.png
> > http://www.geocities.com/kdeprint/slide_2.png
> > http://www.geocities.com/kdeprint/slide_3.png
> 
> Thanks a lot for the screenshots.
> This makes it much easier for me to understand.

This looks very nice.  The third example does a good job of showing the
relationships between options.

> *OpenGroup: PrintoutMode
> 
> matches to a main keyword (*PrintoutMode).
> 
> We may agree that if a option group name is the same as a main keyword
> this option group belongs to the main keyword exactly the same
> way as in the PrintoutMode example - i.e. the option group
> "PrintoutMode" contains sub-options regarding the *PrintoutMode
> option.
> 
> This agreement would make it possible that the dialogs in KDE
> can be more user friendly but all other existing dialogs would
> still work perfectly well and no information would be hidden
> in an unknown data format inside the PPD file.

This is ok as long as there aren't PPD files out there which have
spurious connections of this type.  Remember that if we have to we can
add extension keywords to the PPD files.

Also, any scheme has to take into account vendor PPD files.  Lot of them
don't use grouping.  However they generally use feature names that are
in the PPD spec.  We could have a default list of groups and the options
that go in them.  This could be used to assign groups to any options
that aren't in groups.

How are options that are important enough to be displayed at the top
level to be identified?

> > My first idea was to put the XML data in comments at the end of
> > the PPD file, as Foomatic did. This is compliant with PPD specs.
> 
> It is only syntactically compliant with PPD specs. but this
> way you could have any proprietary format and call it a PPD file
> because you could hide all information as comments.
> According to my understanding the PPD spec. describes a general
> way how to deal with various printer capabilities.
> Of course any printing system or application program (i.e. any
> software which must deal with various printer capabilities)
> must be able to understand the information which is specified
> in terms of a PPD file.
> Therefore hiding information as comments is not in compliance
> to the intention (i.e. the real meaning) of the PPD specs.
 
I agree.  I have nothing against XML, but I don't think we should need to
use both a PPD parser _and_ XML parser to build a user interface.  I am 
about to implement a very similiar interface in Perl/Tk.  I don't want to have
to parse XML in order to extract this tiny bit of additional
information.

Would a filter that read a PPD file, extracted the UI information, and
presented it as XML be useful?

> Regards,
> Johannes Meixner
> -----------------------------------------------------------
> SuSE Linux AG, Deutschherrnstr. 15-19  Mail: jsmeix suse de
> D-90429 Nuernberg, Germany         WWW: http://www.suse.de/
> -----------------------------------------------------------
> 
> 
> _______________________________________________
> Foomatic-devel mailing list
> Foomatic-devel linuxprinting org
> http://www.linuxprinting.org/cgi-bin/mailman/listinfo/foomatic-devel