Printing Trends in Linux (O'ReillyNet) [LWN.net]

Printing Trends in Linux (O'ReillyNet)

Posted Sep 21, 2007 14:19 UTC (Fri) by hmh (subscriber, #3838) [Link]

Indeed. That was nearly-FUD crap, and from an unexpected source, too. It makes me sad.

And any printer that requires binary drivers is just yet another second class piece of crap, IMO. One should either publish open drivers and specs, or have a strong, fast, built-in postscript level 3 *and* PDF (in its latest version!) interpertor inside, with proper PPDs so that we can set printer job options.

But this is not what many of the printer manufacturers want, especially some of the japanese ones. Remember to vote with your wallet *always* when it comes to printers. Never get one whose manufacturer is not providing an open driver, or a suitable firmware and PPD that does away with the need for a driver.

Printing Trends in Linux (O'ReillyNet)

Posted Sep 21, 2007 22:30 UTC (Fri) by rlk (guest, #47505) [Link]

So if the PDF interpreter is embedded in the printer, what happens when a new version of PDF is introduced? Does the printer become a brick? Do you have to download a new binary blob to the printer?

There are real advantages to having a host side printer driver, as I explained in my previous post. Host side printer driver doesn't have to mean proprietary binary driver.

Printing Trends in Linux (O'ReillyNet)

Posted Sep 23, 2007 19:07 UTC (Sun) by eklitzke (subscriber, #36426) [Link]

I think you would just need a tool to translate from the newer version to the old version. Mostly the new features in PDF have been things for interactive documents (or support for new esoteric image formats), and don't affect the printed output of the document. AFAIK most PDF tools, including printing drivers, are still using PDF 1.4 or thereabouts for this reason -- in general you can just ignore the new stuff and have the document print out correctl.

Printing Trends in Linux (O'ReillyNet)

Posted Sep 23, 2007 19:38 UTC (Sun) by rlk (guest, #47505) [Link]

There's no guarantee that that wouldn't change in the future, or that some new page description language wouldn't come along to supplant PDF. What happens if there's a bug in the firmware implementation of PDF, or some kind of back door (something that figures out what you're printing, say, and logs it)? Not that that couldn't happen with a dumb raster printer, but it would be a lot harder.

The issue really isn't where the RIP resides. It can be on the host just as easily as on the printer. If it's on the printer, what's more likely to happen is that manufacturers will distribute binary firmware blobs, which will still cause problems for free distributions (look at the popular HP LaserJet 1018 for an example of that). At least if the RIP is on the host we have a fighting chance of getting specs and writing a free driver.

BTW, the tool to translate from the newer version to the older version is simply a driver, whatever particular gloss you want to put on it. CUPS (and indeed all printing systems) are implemented as chains of drivers. To print a typical PostScript document, CUPS first translates from PostScript to a more limited version of PostScript (pstops), then from PostScript to CUPS raster (pstoraster), then from CUPS raster to whatever the printer needs (rastertogutenprint or whatnot), and finally a back end (USB, vendor-specific USB, IPP or LPD for a network printer, etc). The big issue seems to be the rasterto* layer.

Printing Trends in Linux (O'ReillyNet)

Posted Sep 27, 2007 10:51 UTC (Thu) by drag (subscriber, #31333) [Link]

I don't think PDF support in printers is a good idea either.

Anyways it's easy to translate PDF to postscript and visa versa. PDF is purposely designed that way.

And if anybody things printing in Linux is easy.. buy a cheap lexmark printer. (actually don't. it's a shitty printer that won't work with Linux unless you kill yourself trying first)

Printing Trends in Linux (O'ReillyNet)

Posted Sep 27, 2007 12:37 UTC (Thu) by rlk (guest, #47505) [Link]

Actually, PDF has a number of advantages over PostScript. For one, it's really designed as a page description language; PDF files should render identically on all such printers. Also, it's a lot easier for malicious PostScript to lock up a printer. There are other people here who can speak to all of this more authoritatively than I can...

Lexmark printers and Linux

Posted Oct 2, 2007 11:09 UTC (Tue) by pr1268 (subscriber, #24648) [Link]

Didn't I hear some time ago that Lexmark was a spinoff of IBM? Something to do with an antitrust suit or similar?

Ironic, really, seeing how IBM is a big supporter of Linux these days.

I convinced my dad (Windows-only user) to take my Canon S520 in exchange for his HP DeskJet 5150 right after I abandoned using Windows. He obliged, and I now have a printer that always Just Works™ with Linux and CUPS.

IMO setting up a graphics/video card is more difficult in Linux than setting up a printer.

Printing Trends in Linux (O'ReillyNet)

Posted Sep 25, 2007 1:56 UTC (Tue) by hmh (subscriber, #3838) [Link]

Indeed. That was nearly-FUD crap, and from an unexpected source, too. It makes me sad.

I should apologise for this one. Upon a second reading of the article, I have to say that "nearly-FUD crap" was quite undeserved. It is true that printers from some manufacturers have been dead easy to set up and use for at least two years, but that's about the only point I disagree with in the article. And I do have to agree that's mostly because I consider printers with closed-source or missing drivers as a reason to never get any consumer products from that manufacturer, so I never have anything like that around, not even at work.

On the other hand, I still think binary drivers are a BAD idea, even if they come with the source and a proper license (i.e. a DFSG-compliant one, IMO). Frankly I don't expect open drivers to remain as necessary to printer manufacturers as they are now once binary blobs are easy to deploy.

There are precious few printer manufacturers with a very good track record on open drivers, and I don't want to see any of the binary-only-land happy ones get any more market share from those who like open, DFSG-compliant "free as in beer" drivers.

Printing Trends in Linux (O'ReillyNet)

Posted Sep 20, 2007 21:26 UTC (Thu) by danielhedblom (guest, #47307) [Link]

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.

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.

Printing Trends in Linux (O'ReillyNet)

Posted Sep 20, 2007 21:43 UTC (Thu) by jwb (guest, #15467) [Link]

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.

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)!

Printing Trends in Linux (O'ReillyNet)

Posted Sep 22, 2007 18:06 UTC (Sat) by rlk (guest, #47505) [Link]

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.

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.

Printing Trends in Linux (O'ReillyNet)

Posted Sep 27, 2007 19:36 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

> different distributors take different approaches and basically supply
> different driver API's
...
> we've had to support three different driver frameworks over the year

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
> 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

> 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

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
> 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.

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

Printing Trends in Linux (O'ReillyNet)

Posted Sep 28, 2007 1:03 UTC (Fri) by rlk (guest, #47505) [Link]

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.

>> different distributors take different approaches and basically supply different driver API's
>...
>> we've had to support three different driver frameworks over the year

> 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.

Printing Trends in Linux (O'ReillyNet)

Posted Sep 28, 2007 8:29 UTC (Fri) by nim-nim (subscriber, #34454) [Link]

> 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.

Printing Trends in Linux (O'ReillyNet)

Posted Sep 21, 2007 4:04 UTC (Fri) by dkite (guest, #4577) [Link]

Have you any experience with binary printer drivers?

I ran a Samsung laser printer for a while. Nice printer, sucky drivers.
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.

The reality is that the desktop especially will be in major flux for the
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.

Derek

Printing Trends in Linux (O'ReillyNet)

Posted Sep 22, 2007 11:32 UTC (Sat) by nix (subscriber, #2304) [Link]

CUPS 2.x doesn't exist. Do you mean 1.2.x?

(And yes, Samsung's drivers are awful, but at least for my ML-2250 the
standard pxlmono driver works fine, although at a max of 600dpi rather
than the 1200dpi the printer is theoretically capable of.)

on LSB maturity

Posted Sep 21, 2007 13:32 UTC (Fri) by gvy (guest, #11981) [Link]

> Why is LSB bad you think?
Because it's not cooked yet a thing being too much hyped as a solution.
http://www.livejournal.com/users/udrepper/8511.html

Not that it's utterly fundamentally broken but _currently_ it's still more of a buzzword, not something robust.

Printing Trends in Linux (O'ReillyNet)

Posted Sep 20, 2007 22:49 UTC (Thu) by rlk (guest, #47505) [Link]

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.

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.

Printing Trends in Linux (O'ReillyNet)

Posted Sep 21, 2007 1:13 UTC (Fri) by gtaylor6 (guest, #19812) [Link]

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.

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.

--
Grant Taylor

Printing Trends in Linux (O'ReillyNet)

Posted Sep 21, 2007 4:16 UTC (Fri) by jwb (guest, #15467) [Link]

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)

Posted Sep 21, 2007 9:49 UTC (Fri) by jengelh (subscriber, #33263) [Link]

>If a printer doesn't support open standards (read: postscript)

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.
So, is the PCL/LJ rastering in CUPS open enough?

>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.
* 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).