[lug] Inexpensive Laser Printer (a quick review)

Mon Oct 1 12:06:32 MDT 2001

I hope you don't see this as off topic... - but have any of you looked at cups ( 
http://www.cups.org/ )?  It is unfortunately semi-commercial but they have tried 
to address a lot of these issues.  And I have been using it for a while now with 
decent success.  CUPS is certainly not perfect yet but it can eliminate many 
printing issues.

Just food for thought,
Ferdinand

J. Wayde Allen wrote:

> On Sun, 30 Sep 2001, Rob Riggs wrote:
> 
> 
>>Installing this printer gave me a glimpse of one of the uglier aspects 
>>of Linux (and Unix in general). There is no standard printing subsystem.
>>
> 
> Printing under *nix always seems to be an issue.  I have to admit that it
> took me several days to figure out printing under Linux the first time
> around.  The problem is that I'm not sure what should be done, if
> anything.  So ... this seems like a really valid topic for discussion.
> 
> Not intending to be too pedantic, I know that Rob probably knows more
> about this than I, I'm thinking it might be worth digging back into the
> design philosophy for Unix.  Rather than me typing a lot here, it would
> probably be instructive to refer everyone to the "newbie" columns I was
> writing several years back.  These can be found at
> <http://lug.boulder.co.us/docs.html>.
> 
> The key issue has always been that *nix has tried NOT to embed hardware
> specific code into the general OS software.  Designers have always striven
> to keep hardware specific features at the kernel level and the kernel is
> supposed to allow each device to be accessible to the higher level OS
> structure as simple files.  File contents are handled by the higher level
> programs.  The idea has been to minimize the coding required to adapt a
> new piece of hardware to the system.  After all, Unix was invented at a
> time when computer hardware was far less standard than it is today.
> 
> The printing subsystem, if I understand what is meant here, would then be
> the lpr command.  This allowed one to specify the low level printer
> characteristics such as where the printer is located (parallel, serial, or
> network port), its name, and how to talk to it.  You'd then send print
> jobs to the printer of your choice using:
> 
>    lpr -Pprinter_name file_to_print
> 
> You could also send a print job to the printer directly by typing
> 
>    cp file_to_print /dev/printer
> 
> ,but the lpr command in concert with lpd was designed to handle print
> spooling etc..  This subsystem provides the mechanism and logistics for
> getting the file you want to print to the appropriate printer, and since
> it doesn't care about the file contents should work for any kind of
> printer you'd care to use.  It was left up to the user, and/or the program
> creating the print file to create a file of the type that the printer
> could understand (ASCII, PCL, Postscript, etc.)  My guess is that it is
> this last point where most of the problems lie.  You can't just send a
> binary file to the printer without first converting to a format the
> printer understands.
> 
> Here is where things get a bit sticky.  In MSDOS/MSWindows you have the
> so-called device driver.  This is philosophically a bit different that a
> kernel module in Linux since the driver contains both the hardware
> interface code, and often the data conversion code.  In Linux the idea
> with the lpr command is to use data "filters".  Filters are supposed to be
> the code that converts one specialize file format into the language that
> the printer recognizes.  You can write your own, and/or find these filters
> on the net.  The lpr command has a series of filter identifiers
> (c,d,f,g,l,n,p,t,v) that specify which filter should be used.  Some of
> these may be hard coded in the lpr specification, but as memory serves you
> have to specify the path to the filter location associated with each of
> these letters in the /etc/printcap file along with the printer
> description.  I think that lpr is "old" in the sense that there are only a
> limited number of printer filter identifies.  However, there has been a
> solution.
> 
> When building the printer description in the /etc/printcap file one
> specifies the default filter to be used when no filter option is
> specified.  Then what has typically been done is to write this default
> filter so that it can read the magic numbers out of the printer files and
> decide what if any conversion needs to be done.  These filters are usually
> called "magic filters" and eliminate the need for the user to know what
> kind of file conversion needs to be done.
> 
> The advantage in this kind of world is that programs that want to print
> somewhere don't need to know anything about the printers.  They simply
> need to create a file that is understood by the magic filter and to send
> their output through the lpr print subsystem.
> 
> 
>>Samsung has to provide seperate packages and give seperate instructions 
>>for every major distribution. There is no way to distribute a seperate 
>>ghostscript driver (ghostscript device drivers are all compiled into a 
>>monolithic program). These problems have to be addressed if we are to 
>>ever see better printer support under Linux.
>>
> 
> This is unfortunate, and I wonder if it is caused by approaching this as a
> printer "driver" problem?  If they used the *nix philosophy it should be
> relatively simple to create a kernel module with the minimum code needed
> to talk to the device.  Then they'd only need to build a magic filter
> designed to print standard file formats (ASCII, JPEG, TIFF, Postscript,
> PCL, etc.).
> 
> My guess is that there are actually several issues:
> 
>    - Misunderstanding the *nix design philosophy and treating this as
>      MSWindows style driver
> 
>    - Use of non-standard, proprietary printer languages
> 
>    - Confusion about just where these files should go in a distribution
> 
> Of course, I may also have just completely missed the point.  In any case,
> printing is a common topic with some serious stumbling blocks that should
> probably be discussed.
> 
> - Wayde
>   (wallen at lug.boulder.co.us)
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> 

-- 
Ferdinand Schmid
http://www.archenergy.com
303-444-4149 x231