Jens, thanks for your thoughts. In short, the LSB Certification
process consists of self-testing, combined with as comprehensive a
test suite as we can build. The results of the test suite are
uploaded to the LSB. We're not looking to test the printers (or
apps, or distros) ourselves.
For printing, the test suite could be as simple as a fancy Postscript
file, with lots of fonts, graphics, odd Postscript features, etc.
The bigger focus, though, would be on agreeing what is a reasonable
minimum set of PPDs to ship with a certified distro, and then
building the infrastructure for a semi-automated download of the PPDs
for printers that are not included. That is, a printer could be LSB
Certified if it either 1) plugged in and just worked on a certified
distro or 2) plugged in and after confirming that it was OK to
download and install a PPD from linuxprinting.org, just worked.
The model here is that Certified for Windows print drivers can be
automatically downloaded from Microsoft as part of the printer driver
install process (although, for various reasons, this rarely works as
well as it should).
I don't think I'm suggesting anything radically new here, other than
a commitment by FSG management to work with the printing vendors and
distros to get them engaged in a printer certification process. It
will be up to Till and the printing workgroup to define exactly what
the test suites will entail.
- dan
--
Dan Kohn <mailto:dan at dankohn.com>
<http://www.dankohn.com/> <tel:+1-415-233-1000>
On Mon, 2006-08-21 at 09:58 +0200, Stark, Jens wrote:
> Dan said:
>> Rajesh said:
>>> "All LSB certified printer drivers will work on all LSB
> certified
>>> distros"
>>> I just want to emphasize how much I support this. I would simply
> it,
>> though, to: "All LSB Certified printers work on all LSB Certified
>> distros".
>>> Please be assured that if you (with Ian's help) can develop the
>> testing infrastructure to make the certification meaningful, we
> will
>> do everything possible to get the distros and printing vendors
> onboard.
>>> Offering a private opinion if I may...
>> This Will Be Difficult.
>> While it sounds easy to put a small inkjet in a box and ship it to
> someone testing it, this is how the typical private end user imagines
> printing. However, if you look ad the mid- to high volume area, you
> talk about devices shipped on palettes, weighing up to (and sometimes
> over) half a ton and needing professional installation.
>> How many testing centers do you expect ?
>> Or should every manufacturer be able to do their own testing ? (Now,
> this makes sense - a printing validation test suite...)
>> How much is testing expected to cost - and who assures neutrality and
> confidentiality ?
> (As in: Who can the printer vendor sue if anything goes wrong?)
>> What do others do ?
>> - Microsoft tests printer drivers. Some of the tested ones (not ours,
> glad to say) blue screen a PC on installation. Apart from being a
> revenue generator for MS and a constant source of trouble, their
> driver certification makes sense to MS - not much to the customer.
>> - SAP ? If you want the very best printing support for your device
> under SAP, they will sell you their services at a reasonable price.
> You end up with something like a device type that has been tested on
> actual hardware and you pay for both the device type and the testing.
> SAP printing is big enough to justify this.
>> - Linux ? There is CUPS (and ESP Print Pro). Again in my personal
> opinion, the only way worth going.
> ESP will write drivers for you (if they must) and test it on actual
> hardware (again, for a fee), but preferably license and support their
> DDK. They will even host any PPDs that come their way and maybe even
> have a look at your drivers.
>> The logistics of hardware testing make printer certification difficult
> at least.
>> What DO we need ?
>> - A printer certification suite for CUPS.
>> Okay - "it prints the test page" is more or less that, but is it
> really sufficient ?
>> - CUPS working out of the box on any non-niche distro (i.e. the
> typical general purpose ones. Not the kind that runs on a smark card,
> wrist watch or ICBM.)
>> No major changes, no "we know better than Mike Sweet how this is
> supposed to work", no "oh, let's invent yet another GUI and make
> things soo much simpler for the user". Again, the ability to run CUPS
> without having to look at the specifics of certain distributions. We
> have supporters to train and their job is already pretty difficult.
> And no matter if you sell a distro with a toad, pink pith helmets or
> documented in hungarian portugese, or one that is built and updated
> exclusiviely via UUCP file transfers - if it runs CUPS, we want to
> administer CUPS. If distro X breaks that, it might end up on a "not
> supported" list. It requires extra training just for one distro. See
> the point ?
>> IF there must be yet another GUI (the web interface is fine, thank you
> very much), it should be one and the same for everybody.
>> - Portable printer drivers.
> This is hopefully what the whole topic is about. Printer drivers that
> will be buildable (if not only a PPD) and runnable on every system
> imaginable. It Must Compile and It Must Not Crash.
>> The same applies to any funky back-ends, special utilites, GUIs etc.
> pp.
>> - Linuxprinting.org
> (Can we do without ?)
>> [Getting off my private soap box now]