Printing Trends in Linux (O'ReillyNet)

Printing Trends in Linux (O'ReillyNet)

Posted Sep 28, 2007 8:29 UTC (Fri) by nim-nim (subscriber, #34454)
In reply to: Printing Trends in Linux (O'ReillyNet) by rlk
Parent article: Printing Trends in Linux (O'ReillyNet)

> I think there's a bit of confusion here between Gutenprint (for which I'm
> project lead) and OpenPrinting (which I participate in in my role as
> Gutenprint project lead).

Not at all, since you've implied commonality of interests and alignment of reflexion with the OpenPrinting guys I've answered you as to speaker for the "printer driver" community

>> No, that means printer manufacturers must work together on a single
>>common driver codebase with frequent stable releases distributions can >>easily package both before a distribution release and later as a in-cycle
>>update.

> Good luck getting that to happen.

The OpenPrinting things does not go in the right direction indeed

> The only major cross-vendor driver
> package for inkjets *is* Gutenprint. The individual vendors at best
> release drivers for their own printers (open source in the case of HP,
> partially proprietary in the case of Epson, and not at all in the case of
> Canon).

Nevertheless that's the only working solution and instead of telling the OpenPrinting people "I understand you, I agree on the need to be able to short-circuit distros to distribute drivers" you should tell them "work with me on a common project and your stuff will be distributed by the normal distribution channels".

> We went the pure source route and let distributors and end users compile
> it.

So why do you feel what's right for you is not right for the OpenPrinting people?

> The problem we've had (again, as Gutenprint lead) is that each
> distribution comes up with its own administration tools for printing,

That's because printing administration tools writers didn't come with a solution that satisfies distribution needs, so distributions had to serve themselves. From the printer community side all you can do is create the greatest admin tools distros can't ignore or help your users report problems on distro admin tools so the distributions fix their stuff faster.

> and uses a different database to store information about printing.

And that's the direct fault of the printer driver community for not agreeing on a single database in the first place. Don't blame distributions for making different choices, blame yourself for giving them this choice.

The printer driver community did agree to align its efforts on a single spooler, Cups, and distributions magically all converged on Cups.

> Gutenprint can generate CUPS PPD files and Foomatic XML data

Which is a mistake if you want distributions to choose one of them only

>> 1. agree with all the driver providers on a single driver code project,
>> so you can make it obviously better than the others and have
>> distributions focus on it
> That just isn't going to happen: there are too many printers out there for
> any one volunteer project to support all of them.

If there's no driver it can't be distributed as a binary. If there is a binary it can be distributed as source.

>> 2. have a fast release schedule so there's always a fresh & stable driver
>> code collection for distributions to package when they hit release time.

> We release when we have enough changes to usefully do so. However, there's
> a somewhat delicate tension between "fast release" and "stable", and
> sometimes we have to distribute beta quality drivers for new printers to
> let them stabilize.

So just release the beta part in a separate archive, so distros can easily strip it when they need to do a in-cycle update and have no time for QA on the beta part.

>> 4. Listen to distribution feedback, make the packagers trust you to fix >>stuff quickly when one of your releases have a problem
> We listen to distribution feedback when we receive it. However, sometimes
> we don't receive it, and distributors try to fix things on their own
> without discussing them with us first.

The people in charge of kernel drivers for major distributions have acknowledged they've been guilty of not working with upstreams in the past, and I doubt their printer people feel any different. So this is something for the distributions to fix. However it is easier for distributions to follow a single kernel code source than the numerous competing printing stuff projects out there, so it will be fixed faster if the printer people worked together in the first place.

> Two big examples that come to mind are one distribution (one of the more
> solid ones, in fact) that started using 4.3 (development) releases despite
> warnings that they should stick with 4.2 (stable) releases,

Means your release cycle is too long, and this distribution felt it could not wait for the next stable point.

> and a distribution that tried to work around the paper margin issue in
> 5.0.0 via a really ugly hack.

Means the distribution
1. didn't trust you to fix it in time or
2. fell to the same shortcut logic I'm blaming OpenPrinting for adopting, but you think is just fine

1. is an issue of trust and trust is damn hard to earn unfortunately, 2. is something major distributions are working on but is easier when they have a single organized entity (like xorg or lkml) to talk to.

> If the distributors don't discuss things with us ahead of time -- and some
> do, but some don't -- it's very hard for us to see what's going on.

While discussing is good, having a clear coherent printing roadmap distros can work on without needing to discuss is better.

---

(Log in to post comments)