[Printing-architecture] Printer dialog generation
mike at easysw.com
Mon Aug 28 04:35:13 PDT 2006
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
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
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:
> * 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
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
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
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
More information about the Printing-architecture