[Printing-architecture] Printer dialog generation

[Printing-architecture] Printer dialog generation

[Josef Spillner]

Hello,

a few weeks ago I talked to some people about the possibility of having print 
dialogs generated from a formal schema and some GUI generation hints.
[I hope this is the correct list for such topics.]

I'm involved with research in this area, particularly in ad-hoc usage of web 
services, but most of the concepts apply to any schema-based GUI generation. 
A schema in the world of printing would be a data model which includes 
choices about the paper size, printer capabilities and document-specific 
options.

Creating type-safe dialogs which represent the schema are not an issue, there 
are proven concepts and we have work in progress code for KDE, for example. 
However, creating GUIs which follow HCI standards and are at least basically 
usable is a challenge. Layouting algorithms in particular are not well 
explored yet and almost always need human correction.

As someone not coming from the world of printers, I find PPD files slightly 
weird, to put it mildly. They contain both information about printers and 
interaction code akin to an embedded programming language. However, they seem 
to contain all the necessary information needed for user configuration, 
especially multi-language strings.

Now there are a few questions to those who could help:
* What are the issues with current print dialogs that could or should be 
solved with GUI generation?
* Are there other printer description formats I should have a look at?
* Is there any work being done in this area already?

Josef

Re: [Printing-architecture] Printer dialog generation

[Till Kamppeter]

The printing dialog is one of the main subjects of the upcoming FSG
OpenPrinting Summit in Lexington, KY, which I am organizing together
with the Free Standards Group:

http://www.freestandards.org/en/OpenPrinting/SummitLexington

There is already work in progress about printing dialogs and usability
at OpenUsability.org. This work started on the OSDL Printing Summit in
Atlanta, which I organized together with the OSDL in April this year.

The subject will be continued on the upcoming Summit:

http://www.freestandards.org/en/OpenPrinting/SummitLexington#Printing_Dialog

So I recommend to discuss this on the printing-summit mailing list (I
have cross-posted it to there now), and also on the Summit itself.
Josef, you are also invited to attend the Summit, to meet the printing
and desktop developers and also the OpenUsability team.

   Till


Josef Spillner wrote:
> Hello,
> 
> a few weeks ago I talked to some people about the possibility of having print 
> dialogs generated from a formal schema and some GUI generation hints.
> [I hope this is the correct list for such topics.]
> 
> I'm involved with research in this area, particularly in ad-hoc usage of web 
> services, but most of the concepts apply to any schema-based GUI generation. 
> A schema in the world of printing would be a data model which includes 
> choices about the paper size, printer capabilities and document-specific 
> options.
> 
> Creating type-safe dialogs which represent the schema are not an issue, there 
> are proven concepts and we have work in progress code for KDE, for example. 
> However, creating GUIs which follow HCI standards and are at least basically 
> usable is a challenge. Layouting algorithms in particular are not well 
> explored yet and almost always need human correction.
> 
> As someone not coming from the world of printers, I find PPD files slightly 
> weird, to put it mildly. They contain both information about printers and 
> interaction code akin to an embedded programming language. However, they seem 
> to contain all the necessary information needed for user configuration, 
> especially multi-language strings.
> 
> Now there are a few questions to those who could help:
> * What are the issues with current print dialogs that could or should be 
> solved with GUI generation?
> * Are there other printer description formats I should have a look at?
> * Is there any work being done in this area already?
> 
> Josef
> 
> _______________________________________________
> Printing-architecture mailing list
> Printing-architecture@lists.freestandards.org
> http://lists.freestandards.org/mailman/listinfo/printing-architecture
> 

Re: [Printing-architecture] Printer dialog generation

[Michael Sweet]

As Till has already pointed out, this is something we will be
discussing at the next summit...  I'm actually the person that is
supposed to be reporting on the available options at the next summit to
jump start the work in this area - I'll reply in-line to your
questions...

Josef Spillner wrote:
> ...
> Now there are a few questions to those who could help:
> * What are the issues with current print dialogs that could or should be 
> solved with GUI generation?

There are two main driving factors behind it:

     1. Manufacturers of high-end printing solutions (hardware and
        software) want to provide greater control over print jobs
        than is possible via PPD files and what is normally provided
        by applications - mainly in the area of finishing (binding,
        folding, stapling, punching, etc.) but also for work flow
        management.

     2. Application-specific printing options/panels that can be
        used with multiple print dialog implementations, ultimately
        to allow support for a common (XDG/user-selected) print dialog.

> * Are there other printer description formats I should have a look at?

UPDF was an attempt by the PWG to define a printer description format
that went beyond just PostScript, however it has not been adopted by
anyone that I know of and I personally am not a big fan of it:

     http://www.pwg.org/updf

> * Is there any work being done in this area already?

At this point we are more in an information-gathering phase.  I've
reviewed the (many!) XML (and other text-based) user interface
description formats that could be used and am preparing a report
for the printing summit.

XUL (Mozilla.org's XML UI language) is clearly the most widely
deployed and most capable, however it also carries a significant
overhead for implementation - code exists and could be fairly easily
integrated with KDE and GNOME via XULRunner, however you'll add a
significant amount of code (the XULRunner source code is 33 megs
bzip'd!), so I'm not too keen on using XULRunner or XUL as-is.

Ultimately we need to get better requirements for *what* needs to
be supported, from printer and applications vendors *and* from users
and administrators who may want to add site-specific stuff to the
print dialog, too.

So far our requirements list is pretty short (and challenging):

     1. Cross-platform (operating system, architecture, desktop, UI
        toolkit)
     2. No binaries (executables or plug-ins)
     3. Embeddable in PPD files or some other way to package the UI
        such that the UI and printer description/command data are
        available via a single URI
     4. Same level of localization possible as with current PPD
        files.
     5. Accessible to persons with disabilities

What we don't have is a list of required UI elements and behaviors
that need to be supported.  I'd like to put together sample use cases
we can use as a baseline to determine these requirements and then
form the basis of a test, conformance, and demo suite for the new UI
"technology" that gets incorporated into CUPS and the various
desktops.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Publishing Software        http://www.easysw.com

Re: [Printing-architecture] Printer dialog generation

[Till Kamppeter]

[ Forwarding to the printing-summit list ]

Michael Sweet wrote:
> As Till has already pointed out, this is something we will be
> discussing at the next summit...  I'm actually the person that is
> supposed to be reporting on the available options at the next summit to
> jump start the work in this area - I'll reply in-line to your
> questions...
> 
> Josef Spillner wrote:
>> ...
>> Now there are a few questions to those who could help:
>> * What are the issues with current print dialogs that could or should be 
>> solved with GUI generation?
> 
> There are two main driving factors behind it:
> 
>      1. Manufacturers of high-end printing solutions (hardware and
>         software) want to provide greater control over print jobs
>         than is possible via PPD files and what is normally provided
>         by applications - mainly in the area of finishing (binding,
>         folding, stapling, punching, etc.) but also for work flow
>         management.
> 
>      2. Application-specific printing options/panels that can be
>         used with multiple print dialog implementations, ultimately
>         to allow support for a common (XDG/user-selected) print dialog.
> 
>> * Are there other printer description formats I should have a look at?
> 
> UPDF was an attempt by the PWG to define a printer description format
> that went beyond just PostScript, however it has not been adopted by
> anyone that I know of and I personally am not a big fan of it:
> 
>      http://www.pwg.org/updf
> 
>> * Is there any work being done in this area already?
> 
> At this point we are more in an information-gathering phase.  I've
> reviewed the (many!) XML (and other text-based) user interface
> description formats that could be used and am preparing a report
> for the printing summit.
> 
> XUL (Mozilla.org's XML UI language) is clearly the most widely
> deployed and most capable, however it also carries a significant
> overhead for implementation - code exists and could be fairly easily
> integrated with KDE and GNOME via XULRunner, however you'll add a
> significant amount of code (the XULRunner source code is 33 megs
> bzip'd!), so I'm not too keen on using XULRunner or XUL as-is.
> 
> Ultimately we need to get better requirements for *what* needs to
> be supported, from printer and applications vendors *and* from users
> and administrators who may want to add site-specific stuff to the
> print dialog, too.
> 
> So far our requirements list is pretty short (and challenging):
> 
>      1. Cross-platform (operating system, architecture, desktop, UI
>         toolkit)
>      2. No binaries (executables or plug-ins)
>      3. Embeddable in PPD files or some other way to package the UI
>         such that the UI and printer description/command data are
>         available via a single URI
>      4. Same level of localization possible as with current PPD
>         files.
>      5. Accessible to persons with disabilities
> 
> What we don't have is a list of required UI elements and behaviors
> that need to be supported.  I'd like to put together sample use cases
> we can use as a baseline to determine these requirements and then
> form the basis of a test, conformance, and demo suite for the new UI
> "technology" that gets incorporated into CUPS and the various
> desktops.
>