[lug] Inexpensive Laser Printer (a quick review)

[Riggs, Rob]

Part of the problem is the proliferation of printing systems. CUPS only
helps if *every* Linux distribution chooses to use it.

PostScript is the de facto standard for printing under Unix. The problem
that CUPS still faces, and is the root of the problem I was trying to
highlight, is that unless your printer speaks PostScript, you are going to
need support for in in ghostscript. (At least we have *that* standard!) If
it's a new printer, your entire ghostscript package needs to be updates. And
what happens when your distribution releases an update to ghostscript
(without your new printer driver)? Bye, bye printer.

After that the printer needs to be registered with the printing system, be
it CUP, LPRng, LPD, etc. Each is different. Each has different config files
located in different places. And each distribution does things differently
enough to make it a pain for the printer manufacturer.

To make matters even more fun, we have to deal with bi-directional printer
protocols. None of the current systems that I know of deal with this problem
at all. At that point, we really do need printer support either in the
kernel or somewhere between the printer daemon and the printer device.


-----Original Message-----
From: Ferdinand Schmid [mailto:fschmid at archenergy.com]
Sent: Monday, October 01, 2001 12:07 PM
To: lug at lug.boulder.co.us
Subject: Re: [lug] Inexpensive Laser Printer (a quick review)


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

_______________________________________________
Web Page:  http://lug.boulder.co.us
Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug