|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Thursday, 2 December 1999||Author: Roger Irwin|
|Published to: featured_articles/Featured Articles||Page: 1/1 - [Std View]|
Linux Printing - Time for Change
This article originated in osOpinion and is provided under the OpenContent License.
With Linux being ever more present in the desktop arena, and being administered by non-technical people on their home computers, a continuous lament is lack of printer support....
The perceived deficiency is that Linux has no printer subsystem, that quality printing requires each application to have specific drivers for each printer, and that the Postscript/Ghostscript combination falls far short of the quality of printing in Windows.
Many of the comments that are seen flying around on the Net indicate that the authors are unfamiliar with Postscript.
Postscript is a very powerful and efficient way of interfacing to printers. It is a page description language (a true programming language in fact) that allows an accurate description of what is required to be printed in typographical terms rather than printer specific attributes. As it allows high-level descriptions of objects to be defined and called as objects or routines, it can considerably reduce the amount of data that is to be sent to a printer.
Traditionally, Postscript code is sent directly to a Postscript compatible printer, where a rendering engine knows how to best interpret the page description in terms of the printer's capabilities and characteristics. Postscript on a postscript printer not only produces optimum output, but is also notably faster than solutions that render the page on the host computer and send the image out bit-by-bit.
Postscript is not some invention of Linuxers that they want the rest of the world to support. It has been in widespread use for many years on UNIX systems, but is also used on the Mac and by professional typesetters and printers. The last point should not be undervalued -- Postscript is capable of the highest quality output, and is suitable for e.g. newsstand quality magazines.
Having been the de facto standard for so long, Postscript output also requires zero effort on the part of application developers, GUI development tools include libraries which will automatically produce Postscript output from what has been 'drawn' for the screen.
So, having said how good Postscript is, how come printing on Linux is often so bad and troublesome? Well, if you have a Postscript printer, it isn't. Connect the printer, tell lpd about it, and start doing first-class printing. No driver required! Trouble is that Postscript options tend to be expensive, and are only available on high-end printers. Anything less and you must use a 'filter' such as Ghostscript to convert the Postscript into native code.
Ghostscript, and other Postscript filter developers, have made a fine effort in proving Postscript printing for the printers that 'the rest of us' use, but they are working against the odds. Native code is full of particular quirks and in any case they are working with a generic description of the printer's capabilities. Without the full inside information that only the vendor's own driver coders have, they can never expect to get the same quality that the vendor supplied driver under Windows provides.
Fortunately the situation could be very easily rectified, and with very little effort or expense.
In the first place, although high-end printers justify high-end Postscript rendering engines, budget ink jets could easily be used with lower cost solutions. It would be possible to have Postscript options on low-end printers for less than a hundred dollars. Low cost hassle free driver free printing for all.
Having said that, I am all for minimum cost printers, especially for SOHO use. Why should I pay more for a printer when I only print a handful of pages a week and I am using 128MB PII that could outpace a low cost embedded processor tenfold? Well the obvious next step is for printer manufacturers to supply Postscript filters with the printers. As all serious printer manufacturers have, for many years, produced Postscript renderers for their top end models, this is not exactly new technology for them. Nor need it be Linux specific. A single source should be compilable for most Unix-like platforms, and easily modifiable to other platforms such as the MAC. I wonder how many printer company executives realize that producing Postscript filters for all Unix-like systems would cost them less than a modest advertising campaign?
Postscript filters are not the be all and end all of printing problems however. Another thorny issue is printer-specific features such as which input tray to use, or how to handle color. Postscript has no fundamental problem with this, the application can pass arbitrary parameters to the printer, as well as generic ones such as the size of paper and greyscale vs color. The problem is for the application to know what options are available.
Generally speaking, applications (Netscape for example) limit themselves to a few basic features such as papersize and whether to use color. Even so, they will not indicate to the user what IS possible. You are at liberty to select and A3 color print on an A4 monochrome printer -- the resultant chaos is your problem. This is why some apps (particularly word processors and other programs aimed at hard copy output) have a range of 'drivers' for postscript printers. The drivers detail the capabilities of the printer and allow the relevant control strings to be generated from a printer specific box.
Such a solution is obviously a 'kludge' as these drivers are specific to each application. The Unix world could at this point pinch an idea from Windows (it's about time some good ideas flowed 'the other way around' ;-) ). When you set the 'properties' of a print job in Windows, it calls a properties box that is supplied by the printer driver, the application need not know about sheet feeders and other printer-specific details.
Unix-like systems could easily do things the same way by means of an input filter which gets invoked every time you start to use a printer queue. This would flash up a properties box that allows the setting of such parameters, or simply accepting the defaults, and insert relevant control strings into the head of the printer stream.
More generically, such a popup properties setter could simply produce the control strings on 'standard out'. This would allow an application to call the properties setting in advance, read the control strings, and insert them into the original output, thus paving the way for a more serious approach to printer control under X. The 'input filter' approach could exist concurrently, ignoring print jobs where key parameters had already been set by the app but allowing them to be set on print jobs emanating from apps which do not have support for the properties editor.
What we are saying is that first-class printer support could be easily made available under Linux, and all Unix like systems, without requiring new standards or interfaces, or modifications to existing applications. Nor would it require much development. But it would require the involvement of the printer manufacturers. It is about time printer vendors woke up to the number of people who would like to have their printer supported under Linux/UNIX, and how little effort it would require on their part to make these customers happy. The first to put an 'Includes Linux drivers' flash on their boxes is going to make a lot of friends.
So if you want support for your printer, why not e-mail a copy of this article to your printer manufacturer. Let them know how many of us there are out there!
Roger Irwin lives in Piedmont, NW Italy with his wife and 3-year-old son. He learned to program in Algol on an Elliot 803 computer 26 years ago, and over the years has used more types of systems than he cares to remember. Although, over the last 5 years that he has been using Linux, he has learned more about computing and had more fun than the other 21 years put together. He has always had one foot in computing and one in electronics; needless to say most of his time is spent working on embedded systems and control software.