Printing Trends in Linux (O'ReillyNet)
Printing Trends in Linux (O'ReillyNet)
Posted Sep 20, 2007 20:59 UTC (Thu) by jwb (guest, #15467)Parent article: Printing Trends in Linux (O'ReillyNet)
Another bad idea from the LSB worshippers. Their version of "distribution-independent" mean you just ignore the fact that it's an RPM and your distribution is Debian. Even more moronic is the idea that we should be installing binary printer drivers anywhere. If a printer doesn't support open standards (read: postscript) and if its capabilities can't be exposed with a simple description protocol, don't buy that printer.
Extrapolating from other, historical efforts like these, I give this working group 2 years of toiling in obscurity before they pack it in, and nobody will ever care.
Posted Sep 20, 2007 21:26 UTC (Thu)
by danielhedblom (guest, #47307)
[Link] (8 responses)
An RPM is most often easily made into a .deb with alien as long as the base is the same. I have done this countless times with success on production servers. Nothing stops a package maintainer from doing the same but in a controlled manner.
I dont understand why its so wrong with binary drivers. Sure they arent the best solution but lest a device is destined to be a paperwaight they are a nessecity.
If MS Windows / Mac OS X support a printer and Linux dont, most people outside the zealot fraction tends to think Linux sux, not the printer manufacturer. Its also not a good way to great new Linux users who already owns a printer.
If this group provides a good solution they will prevail. If its all air then they will be forgotten. Most groups like this that has vanished hasnt produced anything useful and therefore disappeared.
Posted Sep 20, 2007 21:43 UTC (Thu)
by jwb (guest, #15467)
[Link] (4 responses)
I don't want "distribution-independent" software. I want software that works well with my distribution. This can't be that big of a burden, considering that my distribution has more than 60,000 packages available. Furthermore my distribution supports thousands of printers without binary blobs and without junk collecting in /opt.
I think we saw recently the kind of quality you can expect from vendor-supplied print software on Linux. Samsung or one of the other vendors shipped a software package which set everything in /usr/bin to be setuid root. That's Kwality(TM)!
Posted Sep 22, 2007 18:06 UTC (Sat)
by rlk (guest, #47505)
[Link] (3 responses)
As the Gutenprint project lead -- and Gutenprint is about as pure a FOSS project as there is -- we've had to support three different driver frameworks over the years: traditional monolithic Ghostscript (the "stp" driver, which we did eventually manage to deprecate -- thankfully!), CUPS, and IJS-based Ghostscript with Foomatic on top of it. Even if we just look at CUPS and IJS/Foomatic, that meant a lot of duplicate work, since the API's are completely different. The only code that's shared between the two is the core driver package itself. So we have to fix bugs in both, come up with different workarounds for things like borderless vs. non-borderless printing (don't -- I repeat, do NOT -- get me started on that!), and every time we make changes, duplicate the testing. And by the way, the user interface to the two drivers isn't identical in the treatment of certain options.
As if that weren't enough, at least one major distribution used its own print tool for a number of years, and we received a lot of support requests for "I can't see the driver for my printer!". The only advice we could really give was to install it from source and use the CUPS web interface (http://localhost:631), which nobody wanted to do because their distribution told them to do it differently. Since I didn't use that distribution, and nobody else came along to package for it, we wound up with a lot of unhappy users.
Then we found another distribution effectively disabled the CUPS web interface on the grounds of security (which the CUPS folks disagreed with, but that's another story). Of course, that distribution (like most others) didn't install the CUPS development package by default, so compiling Gutenprint from source didn't yield usable drivers, making it even harder to tell people what to do. The upshot of it all is that there's no one set of installation and configuration instructions that works everywhere, and that's not a good thing.
Vendors keep coming out with new printer models, so we have to keep adding support for new printers, and none of that follows distribution release cycles (and it would hardly be reasonable to ask Epson to follow the release cycle for Fedora, OpenSUSE, Ubuntu, Debian, and so forth -- not to mention that the distributions themselves aren't on the same cycle, and there's no reason they should be). Not to mention that people don't want to have to upgrade their distribution just because they've bought the latest printer on sale. But what it does mean is that there has to be a reasonably straightforward way to install new printer drivers on top of an existing distribution. And that way does have to be reasonably distribution-independent. We can't keep track of every release of every distribution out there. Note that this has nothing to do with proprietary vs. free source.
For many years, Debian handled it by uploading new releases of Gimp-Print and Gutenprint on a regular basis, thanks to the unstinting efforts of one particularly dedicated individual (Roger Leigh). But unless every distribution is willing to devote someone to every driver project (which also has a scalability problem), that method won't work too well either.
Posted Sep 27, 2007 19:36 UTC (Thu)
by nim-nim (subscriber, #34454)
[Link] (2 responses)
So you've contributed to three different frameworks equally, making none obviously better feature-wise than the others, and you wonder distributions didn't know which one to distribute?
> So we have to fix bugs in both, come up with different workarounds for
And time is wasted there, which you try to make up for by short-circuiting distribution release cycles
> Vendors keep coming out with new printer models, so we have to keep
Not a problem - every distribution does in-cycle updates provided your code release process is reliable and frequent enough shipping an update in-cycle is possible in the first place
> But what it does mean is that there has to be a reasonably
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.
You're reinventing the third party binary drivers hell major distributions have spent major efforts weaning hardware manufacturers of, and you don't even have the constraints that make kernel updating difficult.
Stop trying to do distribution and integration work in the distribution stead, focus on providing distributions what they want (a reliable code source), and your problems will just vanish. You've got enough problems on the code side without getting in the binary distribution business too.
Speaking has someone who packaged distribution material for years, you're a victim of the common "distributions hate me" developer syndrome, where a bad source code release policy results in delays in the distribution-side propagation of your stuff, and instead of trying to understand why distributions can not work with your code releases, you try to short-circuit them and design custom binary payload distribution circuits instead. These attempts almost always fail miserably, because users have other things to do than learn a gazillon different installation methods, and anyway without the distribution integration QA level the result is a windows-like mess. But in the meanwhile all the useless stuff you've added to enable direct binary distribution makes your source even less easy to build cleanly for distributors, and you've wasted everyone's time.
The working strategy is:
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
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.
3. always release solid code so distributions know they can rebuild new versions in-cycle as updates without fearing it will go bang on user systems
4. Listen to distribution feedback, make the packagers trust you to fix stuff quickly when one of your releases have a problem
Posted Sep 28, 2007 1:03 UTC (Fri)
by rlk (guest, #47505)
[Link] (1 responses)
>> different distributors take different approaches and basically supply different driver API's
> So you've contributed to three different frameworks equally, making none obviously better feature-wise than the others, and you wonder distributions didn't know which one to distribute?
More accurately, we (Gutenprint) have *supported* three different frameworks (different API's) -- basically, competing standards for drivers. Otherwise we'd be limiting who could use Gutenprint. Distributors pick their preferred driver framework; we don't get to make that decision for them.
>> So we have to fix bugs in both, come up with different workarounds for things like borderless vs. non-borderless printing (don't -- I repeat, do NOT -- get me started on that!), and every time we make changes, duplicate the testing.
> And time is wasted there, which you try to make up for by short-circuiting distribution release cycles
No, we just have to make sure that Gutenprint works with both of the currently-supported driver frameworks (CUPS raster and Ghostscript/IJS/Foomatic). People get really unhappy if we don't do our testing and we break their printer.
>> But what it does mean is that there has to be a reasonably straightforward way to install new printer drivers on top of an existing distribution.
> 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 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).
> You're reinventing the third party binary drivers hell major distributions have spent major efforts weaning hardware manufacturers of, and you don't even have the constraints that make kernel updating difficult.
> Stop trying to do distribution and integration work in the distribution stead, focus on providing distributions what they want (a reliable code source), and your problems will just vanish. You've got enough problems on the code side without getting in the binary distribution business too.
Come again? The only binaries we distribute are for OS X, which is a special case. We do not distribute binaries for anything else. For that matter, we kicked all of the distribution-specific packaging (Debian control files, RPM .spec files) out of our source base before 5.0; we decided that either we had to support every distribution (which is of course hopeless) or just distribute source. We went the pure source route and let distributors and end users compile it.
> Speaking has someone who packaged distribution material for years, you're a victim of the common "distributions hate me" developer syndrome, where a bad source code release policy results in delays in the distribution-side propagation of your stuff, and instead of trying to understand why distributions can not work with your code releases, you try to short-circuit them and design custom binary payload distribution circuits instead. These attempts almost always fail miserably, because users have other things to do than learn a gazillon different installation methods, and anyway without the distribution integration QA level the result is a windows-like mess. But in the meanwhile all the useless stuff you've added to enable direct binary distribution makes your source even less easy to build cleanly for distributors, and you've wasted everyone's time.
I think this is the exact reverse of the true situation -- it's certainly the opposite of what I think I'm frustrated about.
The problem we've had (again, as Gutenprint lead) is that each distribution comes up with its own administration tools for printing, and uses a different database to store information about printing. Gutenprint can generate CUPS PPD files and Foomatic XML data, but that isn't always how distributors package their printing data, so if an end user wants to try our latest code drop, they don't manage to integrate it and complain (with merit) about the situation.
It isn't as bad as it was maybe 3 years ago, but even now SUSE expects you to use YAST to configure printers (and doesn't support http://localhost:631 out of the box), Fedora has its own tool, and I have no idea what other distributions do. So it doesn't matter, source or binary, users aren't able to pick up our latest driver package and "just use" it.
> The working strategy is:
> 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. In any case, there are standards for drivers -- CUPS raster and IJS with Foomatic data -- that work. I'd rather see all the distributors switch to CUPS and use CUPS PPD files as their database, and support the web interface to CUPS as their primary administrative interface, but that doesn't seem to have completely happened.
> 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.
> 3. always release solid code so distributions know they can rebuild new versions in-cycle as updates without fearing it will go bang on user systems
See above about testing. We try very, very hard to avoid incompatible changes during stable release trains (4.2 and 5.0). I'm very proud of what we did with 4.2. I also think 5.0 is a very good release. Unfortunately, we did have to make an incompatible change (related to margins) in 5.0.1. Even more unfortunately, we could only do it for the native CUPS driver; there was no way to do it with Foomatic.
> 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. 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, and a distribution that tried to work around the paper margin issue in 5.0.0 via a really ugly hack. 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.
Posted Sep 28, 2007 8:29 UTC (Fri)
by nim-nim (subscriber, #34454)
[Link]
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
> Good luck getting that to happen.
The OpenPrinting things does not go in the right direction indeed
> The only major cross-vendor driver
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
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
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,
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
> We release when we have enough changes to usefully do so. However, there's
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
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
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
Means the distribution
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
While discussing is good, having a clear coherent printing roadmap distros can work on without needing to discuss is better.
Posted Sep 21, 2007 4:04 UTC (Fri)
by dkite (guest, #4577)
[Link] (1 responses)
I ran a Samsung laser printer for a while. Nice printer, sucky drivers.
The reality is that the desktop especially will be in major flux for the
Derek
Posted Sep 22, 2007 11:32 UTC (Sat)
by nix (subscriber, #2304)
[Link]
(And yes, Samsung's drivers are awful, but at least for my ML-2250 the
Posted Sep 21, 2007 13:32 UTC (Fri)
by gvy (guest, #11981)
[Link]
Not that it's utterly fundamentally broken but _currently_ it's still more of a buzzword, not something robust.
Posted Sep 20, 2007 22:49 UTC (Thu)
by rlk (guest, #47505)
[Link]
For raster printers -- and all laser, dye sub, and ink jet printers are, when you get right down to it, raster printers -- there are tradeoffs between putting the driver on the host or in the same box as the printer itself. There's obviously the cost issue -- adding a separate controller, large amounts of memory (and inkjet printing at high resolutions uses a *lot* of memory), and firmware isn't free. But there are other advantages that are significant to the free source community to having the driver on the host -- it's possible to do more with it than simply providing 8-bit RGB or grayscale input. It's possible, for example, to have CMYK input, 16 bits/channel, improved screening algorithms, etc. Other people have used Gutenprint (I'm the project lead for Gutenprint) to handle non-standard inks and do other unusual things that the printer vendor didn't think of or doesn't want to support.
Personally, I find PPD files to be very limiting -- you can't express transfer curves, it's very hard to have conditional options, you can't even conveniently express floating point options without the CUPS 1.2 extensions. I'm not the only one who thinks that way -- at least some printer vendors have their own objections to PPD files for analogous reasons. At least, this was true at the last printing summit I attended about 18 months ago.
You can install Gutenprint, HPIJS, foo2zjs, etc. from source if you like. The issue of proprietary binaries is quite distinct from distribution independence.
Posted Sep 21, 2007 1:13 UTC (Fri)
by gtaylor6 (guest, #19812)
[Link] (1 responses)
OTOH, I would argue that your notions about printer interfaces are a bit simplistic. For many, perhaps even most, categories of printer, there are approximately zero products with on-board RIP using ie ps or pdf. In practice this includes more or less all "home" printers, the vast majority of small "desktop" printers for any market, and again the majority of special purpose printers like label, card, kiosk, receipt, disc, or photo devices. Many RIP-free printers are further hobbled by sporting a partly or entirely undocumeted control language.
For now the best course is probably to give LF and Till the benefit of the doubt and see what comes of it. The practical disadvantages of nonfree drivers will be in no way mitigated by any LSB distribution infrastructure; nonfree printer drivers will continue to fail prematurely and generally be a PITA regardless. My only objection will be if any plan surfaces to turn the Foomatic database into a distribution vector for non-free software. This would be quite a turnaround from my original intent, and IMHO a long-term disservice to free software users.
--
Posted Sep 21, 2007 4:16 UTC (Fri)
by jwb (guest, #15467)
[Link]
Posted Sep 21, 2007 9:49 UTC (Fri)
by jengelh (guest, #33263)
[Link]
There is at least one printer model that really sucks with regard to PS; feed it something non-rastered and it will get you "OUT OF MEMORY" and locks up hard - HP LJ2200, kthxbye.
>Their version of "distribution-independent" mean you just ignore the fact that it's an RPM and your distribution is Debian.
While I have to agree that RPM alone is not too nice, the Debian build system is, uh, see yourself:
* pam_mount specfile: 1485 bytes in 1 file.
Why is LSB bad you think? I for one would not like it if Linux went the way Unix did fragmenting into bits making it unduly difficulty for third parties to make applications run on different distributions or even versions of the same distribution. Printing Trends in Linux (O'ReillyNet)
I've been arguing for years that the distributor is the key element that makes Linux as good as it is. Without the editorial function of the Debian, Red Hat, or Ubuntu developers, Linux is just a pile of code. If you try to cut the distribution out of the picture by making "distribution-independent" software, then you are cutting out the most valuable part of the Linux ecosystem.Printing Trends in Linux (O'ReillyNet)
Printing has always been a problem, in no small part because different distributors take different approaches and basically supply different driver API's. Some distributors use Foomatic, some use CUPS native drivers with their own tools layered on top of it, and some have at least historically used their own databases. This makes life a real pain for driver writers, both proprietary and FOSS. Hopefully we can at least standardize this so that those of us in the driver community don't have to duplicate work.Printing Trends in Linux (O'ReillyNet)
> different distributors take different approaches and basically supplyPrinting Trends in Linux (O'ReillyNet)
> different driver API's
...
> we've had to support three different driver frameworks over the year
> things like borderless vs. non-borderless printing (don't -- I repeat, do
> NOT -- get me started on that!), and every time we make changes,
> duplicate the testing.
> adding support for new printers, and none of that follows distribution
> release cycles
> straightforward way to install new printer drivers on top of an existing
> distribution.
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). I'm speaking for Gutenprint here.Printing Trends in Linux (O'ReillyNet)
>...
>> we've had to support three different driver frameworks over the year
> I think there's a bit of confusion here between Gutenprint (for which I'mPrinting Trends in Linux (O'ReillyNet)
> project lead) and OpenPrinting (which I participate in in my role as
> Gutenprint project lead).
>>common driver codebase with frequent stable releases distributions can >>easily package both before a distribution release and later as a in-cycle
>>update.
> 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).
> it.
> distribution comes up with its own administration tools for printing,
>> 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.
>> code collection for distributions to package when they hit release time.
> 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.
> 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.
> solid ones, in fact) that started using 4.3 (development) releases despite
> warnings that they should stick with 4.2 (stable) releases,
> 5.0.0 via a really ugly hack.
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
> do, but some don't -- it's very hard for us to see what's going on.
Have you any experience with binary printer drivers?Printing Trends in Linux (O'ReillyNet)
The driver system attempted to replace packages already installed with
their particular version of Cups that was tested and configured for their
printer. After I ditched it they introduced a security bug with their
sloppy setup. Everything would work until I updated my distro. A bad
situation, especially since it was during the time when Cups 2.x was
starting to be used. Eventually the KDE packages became dependant on v2.0
while the printer drivers used 1.2?. I got rid of the printer right about
then.
forseeable future. For good reason, since it isn't quite finished yet. To
try to lock down something now is foolish at worse, misguided at best.
This isn't zealotry. The distro's I use have a well established and
reliable means of keeping things working. I refuse to purchase a printer
from someone who refuses to work within the maintenance and update
system.
CUPS 2.x doesn't exist. Do you mean 1.2.x?Printing Trends in Linux (O'ReillyNet)
standard pxlmono driver works fine, although at a max of 600dpi rather
than the 1200dpi the printer is theoretically capable of.)
> Why is LSB bad you think?on LSB maturity
Because it's not cooked yet a thing being too much hyped as a solution.
http://www.livejournal.com/users/udrepper/8511.html
I'm not a fan of proprietary binary drivers myself, but I think it's a mistake to insist that all printers natively support PostScript, PDF, or what have you. Don't forget that PostScript and PDF had proprietary origins themselves.Printing Trends in Linux (O'ReillyNet)
I dunno about the LSB being all bad; there are certain areas where non-free binary software is the norm, and areas where that's entirely reasonable. But I would certainly agree that drivers isn't one of those areas. Unfortunately there is implicit in all this packaging talk a goal of making binary printer drivers feasible, even as (for example) the Linux kernel folks discourage binary kernel drivers with ever more vigor each passing year.
Printing Trends in Linux (O'ReillyNet)
Grant Taylor
I'm not trying to be simplistic and require everybody to have a postscript rip in their printer. Indeed, postscript may not even expose the best features of the print engine. I only expect my printers to have some kind of open, documented control language. I plug my Lexmark postscript printer into my Linux machine and it works flawlessly. I plug my Epson CX5400 into my Linux machine and it works perfectly. The latter is, by the way, not true with Windows. So I guess you'll have to excuse me if I'm not seeing the big emergency that requires us to adopt an infrastructure for the distribution of binary print drivers. As far as I can tell, getting a printer that works with the existing infrastructure is a matter of smart shopping.Printing Trends in Linux (O'ReillyNet)
>If a printer doesn't support open standards (read: postscript)Printing Trends in Linux (O'ReillyNet)
So, is the PCL/LJ rastering in CUPS open enough?
* Debian files: 3304 bytes (w/o comments) in 7 or more files. There seems to be quite some redundancy in the [across all deb packages] build scripts (e.g. the .postinst/.postrm scripts).