Hi Tom, Randy, Mike, et al
[Copying the <pwg at pwg.org> mailing list (which is opt-in),
because this topic is of general interest]
Tom - most vendors that offer Universal Print Drivers are
shipping Windows-only, Postscript-only UPDs. That does
not help for Linux netbooks and mobile devices, the target
platform of Google Chrome OS.
For several years, Open Printing folks have been working
on migrating the typical Linux print workflow from PostScript
to PDF.
Unlike Windows and Mac OSX, there isn't yet any standard
print dialog on Linux - coding is now in progress on the OP
Common Printing Dialog - which uses extended PPD files
for internationalized menus of print options and constraints.
See OP home page:
http://www.linuxfoundation.org/collaborate/workgroups/openprinting
But the much larger task is getting the OP CPD into the two
primary toolkits (GTK+ and QT) and getting applications to
USE the toolkits - many high-function print applications
(word processing, graphics layout, photo, BROWSERS,
etc.) on Linux currently include their own print dialog - that
means these applications have to be individually patched
to use the OP Common Print Dialog.
Mike - you're right that a cross-vendor Universal Print
Driver for Linux is technically feasible - but it's a huge
task to validate it against printers from lots of vendors
- and all those vendor-specific image enhancement
features will never be available.
Cheers,
- Ira
Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
email: blueroofmusic at gmail.com
winter:
579 Park Place Saline, MI 48176
734-944-0094
summer:
PO Box 221 Grand Marais, MI 49839
906-494-2434
On Sat, Dec 5, 2009 at 11:22 PM, Michael Sweet <msweet at apple.com> wrote:
> On Dec 5, 2009, at 4:33 PM, Tom Hastings wrote:
>> ...
>> Why wouldn't the XHTML-Print "PDL" be a candidate for the Chrome PDL?
>> Because, unfortunately, the standard does not require support for inline image data so any printing of non-text is a non-starter unless you want to make your thin client a server... There is also the issue of XHTML-Print not being WYSIWYG...
>> (oh, and Ira the issue isn't really driverless printing but being able to print without a vendor-specific driver, which is 100% feasible - obviously there will need to be some sort of driver/generator software to produce printer-ready bits...)
>> ___________________________________________________
> Michael Sweet, Senior Printing System Engineer
>>>>
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.