DJ500 dead after >= 16 years.

Ted Mittelstaedt tedm at
Mon Feb 25 07:08:37 UTC 2008

> -----Original Message-----
> From: owner-freebsd-questions at
> [mailto:owner-freebsd-questions at]On Behalf Of Predrag
> Punosevac
> Sent: Friday, February 22, 2008 1:09 AM
> To: Ted Mittelstaedt; questions at
> Subject: Re: DJ500 dead after >= 16 years.
> Ted Mittelstaedt wrote:
> >
> >> -----Original Message-----
> >> From: owner-freebsd-questions at
> >> [mailto:owner-freebsd-questions at]On Behalf Of Predrag
> >> Punosevac
> >> Sent: Wednesday, February 20, 2008 12:25 PM
> >> To: David Kelly
> >> Cc: Gary Kline; FreeBSD Mailing List
> >> Subject: Re: DJ500 dead after >= 16 years.
> >>
> >>
> >> David Kelly wrote:
> >>
> >>> On Wed, Feb 20, 2008 at 12:02:25AM -0800, Gary Kline wrote:
> >>>
> >>>
> >>>> 	Nutshell, I'd like anyone's ideas/experiences with some of these
> >>>> 	new HP/<<< or whateverbrand>>> printers. I wouldn't *mind* if I
> >>>> 	could scan in text from a techy paper into HTML or PDF or text.
> >>>> 	But mostly, like 99.44%  plain black text.  My old deskjet used
> >>>> 	gs as a filter to print PostScript.  Do we have any such plugin
> >>>> 	support, or are printers still roll-your-own?  [FWIW, I can't
> >>>> 	seem to get CUPS working...  altho it maay be my misssing
> >>>> 	/dev/lpt0.]
> >>>>
> >>>>
> >>>
> >> Why don't you check for
> >> the most comprehensive information available.
> >>
> >> Just couple a comments. I would keep native LPD spooling system instead
> >> installing CUPS unless you need to use something
> >> like HPLIP drivers.
> >>
> >
> > You do not need CUPS for the hplip drivers, you can use lpd if you
> > want.
> >
> > To be perfectly clear on this, all that CUPS is, is 4 things:
> >
> > Spool manager - LPD does this
> >
> > Speaks IPP protocol - LPD also does this except it speaks LPR protocol
> >
> > Easy user interface for the options needed by some of the more complex
> > filters. - lpd does NOT do this BUT, you can do it by writing
> > your own filter script and coding the options you want into it.
> > Note that most options are set once and forget, so CUPS really
> > doesen't add much here.  CUPS uses Postscript PPD files to automagically
> > generate the webpage the user fills out to select these options.
> >
> > web-interface for job mangement - well who needs this for a
> > personal printer attached to a workstation?
> >
> > The reason CUPS is used so much is that it dummifies the
> > chain of hooking together programs into a black box.  So,
> > people who don't understand what is going on can setup a
> > printer by clicking buttons.  That is fine if your printer
> > model is supported.  But if it doesen't work or if the model
> > is a new one that the cups people haven't quite yet got around
> > to testing with, or nobody has written a .PPD file for it,
> > you have to understand what is going on then.
> >
> > I've posted the following before, but here's the instructions
> > I use for setting up my C84 without CUPS, so you can see
> > how this kind of thing works.  They are just a bit old but
> > still work if you change the version #s.  The setup uses the IJS output
> > from Ghostscript and feeds it into gimpprint.  The HPLIP
> > scheme works exactly the same way except that instead of
> > gimpprint, you use the hpijs driver along with the required
> > options:
> >
> > 1) setup print queue
> >
> > Add the following to the end of /etc/printcap:
> >
> > lp-epson|Epson C84 Color printer:\
> >         :sh:\
> >
> > :lp=/dev/lpt0:sd=/var/spool/output/lp-epson:lf=/var/log/lpd-errs:mx=0:\
> >         :of=/usr/local/bin/epsonfilter:rw:
> > lp-epson-raw|Epson C84 Color Printer - raw for Windows systems:\
> >         :sh:\
> >
> > :lp=/dev/lpt0:sd=/var/spool/output/lp-epson-raw:lf=/var/log/lpd-errs:\
> >         :mx#0:rw:
> >
> > Create the print queues:
> >
> > cd /var/spool/output
> >
> > mkdir lp-epson
> > mkdir lp-epson-raw
> >
> > Add in access for the local systems
> >
> > cat /etc/hosts.lpd
> > # $FreeBSD: src/etc/hosts.lpd,v 1.4 1999/08/27 23:23:42 peter Exp $
> > #
> > # See lpd(8)
> > #machine.domain
> >
> >
> >
> >
> >
> > nat-rtr#
> >
> > Run some test prints through the queues:
> >
> > cd /etc
> > ls -l | lpr -P lp-text
> >
> > Send a test print page from the Windows 2K workstation
> > via lpr to the print queue on the BSD box
> >
> > (do a chmod 664 on the lock file in the lp-epson-raw queue,
> since network
> > LPR doesen't set the mask up properly per submitted bug)
> >
> > 2) Install the tools to image a printjob for the Epson, as follows:
> >
> > cd /usr/ports/print/gimp-print
> > make WITHOUT_CUPS=yes
> > cd work/gimp-print-4.2.7/src/escputil
> > ./escputil -i -u -r /dev/lpt0 (checks ink levels)
> > ./escputil -n -u -r /dev/lpt0 (prints nozzle alignment)
> > (try some other commands to see if the level of support is better)
> > cd ../../../../
> > make WITHOUT_CUPS=yes install
> > cd ../ghostscript-gnu
> > make install
> > Deselect all the printers, leave in stp and ijs driver, as well
> > as all the X-windows drivers and the jpg and other image drivers.
> >
> > test the ghostscript install:
> >
> > cd /root
> > man -t which >
> > gs -dBATCH -sDEVICE=jpeg -sOutputFile=test.jpg
> > open test.jpg in a browser and see if the page is there
> >
> > Now test gimpprint and ghostscript:
> >
> > first manually with the command,
> >
> > gs -sDEVICE=ijs -sIjsServer=/usr/local/bin/ijsgimpprint
> -sDeviceManufacturer
> > =EPSON  -sDeviceModel=escp2-c84
> -sIjsParams=Quality=720x360sw,InkType=CMYK
> > ,MediaType=Plain -dIjsUseOutputFD -dNOPAUSE -dBATCH
> -sOutputFile=test.out
> > /usr/local/share/ghostscript/7.07/examples/
> >
> > lpr -P lp-epson-raw test.out
> >
> > Create the file /usr/local/bin/epsonfilter with the following contents:
> >
> > #!/bin/sh
> > #
> > # Script that runs gimp-print for the Epson
> > #
> > /usr/local/bin/gs -q -sDEVICE=ijs
> -sIjsServer=/usr/local/bin/ijsgimpprint -s
> > DeviceManufacturer=EPSON  -sDeviceModel=escp2-c84
> -sIjsParams=Quality=720x
> > 360sw,InkType=CMYK,MediaType=Plain -dIjsUseOutputFD -dNOPAUSE
> > FER -sOutputFile=- -
> >
> > test with firefox and
> >  use the printer lpr -P lp-epson
> >
> > test PS file:  /usr/local/share/ghostscript/7.07/examples/
> >
> >
> This is now a real thing!!! Thank you so much for this how to!
> I was wondering myself why would one need CUPS to use HPLIP but I never
> had the gut to
> ask anybody as I didn't want to look like an idiot. In reality the only
> semi-serious document about setting HPLIP I have seen for
> FreeBSD is Daniel W. Steinbrook's how to which walks you through but
> doesn't explain how the things really work and why does he need CUPS.
> I learned a lot from your The FreeBSD Corporate Network's Guide.
> I would really love to see you personally updating chapter about
> printing in the Handbook.
> Chapter is well written but seems that it lacks details about filters
> and drivers necessary to set printers which speak only PCL.

Yes, that was intentional.  The simple reason was that I was writing
to an audience of newbies.  It is not a good idea to send a newbie
off into the wilderness of configuring non-Postscript printers, as they
are very likely to get into quicksand, and abandon FreeBSD all together.

Back in the late 90's you generally had 3 kinds of printers:

ascii/PCL,  Windows-only printers, Postscript/PCL.

It was pretty easy to tell people to avoid windows-only printers,
and that if they wanted to print graphics they needed to have a
postscript printer.  Since there was only 1 model of inkjet printer
on the market that spoke postscript (the old HP 1600) that was
basically telling the FreeBSD newbie to buy a laserjet printer
if they wanted to print graphics from FreeBSD, otherwise ASCII
printing would work just fine on their inkjet printer.

Since then, the printer manufacturers have introduced these win-printer
laserjet printer abominations, and today few inkjet printers will
speak ASCII.  I was, for example, very surprised that my Epson Stylus
C84 would still print an ASCII page that was catted to the printer,
and I think that this was one of the last models Epson made that could
still do that.

So now, we are getting dragged more and more into configuring these
printers that only speak the proprietary non-PCL language of a
Windows-only printer.  That is why gimprint and HP's print program
have become so popular.

It's a very sad situation.  Postscript is really, really, the way
to go, and Printers like the Brother HL-5240 that list as $200
and that have the BR-Script3 Postscript-lookalike built in, are a
wonderful shining light in a gloomy forest.

> Most  users  including  the University where I work do have some if not
> most printers which do NOT speak Post Script.

If I was in your shoes I'd check to see if any of the printers
had a postscript option.  For example it's very cheap to buy a
Postscript rom off Ebay for any of the larger HP laserjets and
only a few minutes work with a screwdriver to add it.  If your not
the IT administrator, then sneak in after hours and slap that
puppy into the printer.  Since it doesen't affect the PCL-printing
people, the admin isn't going to know.  Most of the Postscript roms
are pretty cheap.

> The knowledge to edit the
> printcap file and how to utilize various filters seems to me as
> paramount importance.
> However, like  probably on many other places the system administrators
> choose "easy"  route which is using CUPS and buying
> printers that are documented to work with PPD files they can get from
> Linux Printing web-site.

Yes, very likely.

> I do not think that they have every used
> foomatic rip to get PPD for a printer.
> Even worse they use Ubuntu for Printer Server and they are clueless what
> is really going on. At some point I was contemplating to buy
> and try to learn how really CUPS does work.
> The problem with that is that the more I learn about Unix Printing it is
> less clearly to me why the hack do we need CUPS anyway.

Because of two major reasons.  The first is IPP itself.  Unlike the LP
protocol, IPP allows the printing clients to query the printer for it's

Ideally, a printer would have a network print server in it that would
speak IPP and have a proprietary connection to the printer innards that
would allow the remote user to find out things like; is the printer out
of paper or not?  Does the printer have a duplexer or not? etc.
The HP Laserjet internal print server cards can do this.  Most external
hardware print servers cannot.  A PC running UNIX and CUPS, being
used as a print server for a locally attached printer, CAN do this.
(CUPS usually fakes it by looking at the PPD file, not talking to
the printer directly)  This is functionality that isn't available
in LP.  (LPR/LPD)

The other reason concerns the USER interface to the printer.

You see, in the "traditional" UNIX way of doing things with LPD,
you had the problem of how to turn on specific options on the
printer for different types of jobs.  When they wrote the lpr
program, they tried to get around this
by introducing options to lpr (-c -g -n, etc.) that would make
lpr run special printer preprocessors that would setup specific
options in the printer. When running specific jobs you would use
whatever option applied, that would turn on the specific feature
on the printer for that job.

This worked for ancient dot-matrix
lineprinters, but the plethora of printers and options in the
post-dot matrix world put an end to that.

So then, the only option was for each major feature you would define a
separate printer name and queue.  For example, for a HP Laserjet 5Si,
you might define 6 queues, one for regular single-sided printing,
one for duplex printing, one for compressed printing, one for landscape
printing, one for landscape & compressed printing, one for envelope
printing on regular envelopes, etc. etc.

When you printed from your application program, you would select
the queue name that cooresponded to the options you wanted.

Each printcap definition would have a filter that would send whatever
control codes were needed for the printer to turn on that option
for that job, then turn it off when the job was completed.

With printers having dozens of options the number of combinations
would get so large that the users wouldn't be able to remember
"OK, do I want to use queue "line-print-compressed-f" or "line-print-com
pressed-g" to turn on the duplexer?

In the Microsoft Windows world, MS solved this by allowing the
application program to make a function call into the printing
system that would allow the application program to display the
printer control panel, the user could set whatever options they
wanted there, and the document would print then the options would
reset when the program was closed.

In the UNIX world the solution to this was CUPS.

An application program such as Open Office if running under a manager
like KDE or gnome, can make a function call to the manager
that displays a similar dialog - that manger makes a library
call into CUPS to do this.

For command line programs that the user is running from the
shell, you can use the CUPS webinterface to find this out
about the printer, that's why it's there.

This is functionality that LP does not have.  If you tried writing
a GUI application that did this without CUPS, you would have to
understand all about PPD files and know where they were located and
how to read them and suchlike.  You would have to know all this
platform-specific information about the UNIX version your running.
That is ugliness that makes programs platform-specific that we do
not really want.

Note this is completely separate from Postscript.  Just because you
can cat a Postscript file to a Postscript printer, that doesen't
help your program to know if the printer has a duplexer on it or not.

> For a really
> novice user I find apsfilter and running ./SETUP script far easier than
> using idiotic CUPS web-tool.
> Native  LPD  system is  easy to trouble shoot, including network
> printing and I am not a system administrator by profession.
> Whole that mambo-jambo thing about security problems with LPD in the
> past seems absurd as even my home printer servers and stations are
> behind two layers of firewalls deep behind in the LAN zone.

Of course you do, why wouldn't you?  Your printer is 5 feet away
and you know all about it's capabilities.

Your not like the user running Open Office at a company like, for
example, IBM, who is printing a special color print job to the
super-expensive high-power printer that's located in the next
building, and the user needs to know if the printer is chewing
away 30 jobs in front of her before she gets up and spends 5
minutes walking over to the other building to get her job.  Oh
and by the way, this printer costs a buck a page to print, so
only certain key people in each department are even authorized to
print to it, the company does not want regular employees printing
pictures of their cat on it to hang up in their cubicile.

The problems that CUPS was written to solve are mostly not problems
that an individual at home with his PC and printer next to it
ever face.  They are problems that are faced in companies and
organizations that have a few good printers with a lot of bells
and whistles and a bunch of people printing to them.

Imagine if a 50 person company allowed each employee to have their own
personal color inkjet printer.  That's an extra $3,000 a month in ink
cartridge costs alone that the company would likely bear.  It's
out of the question.

> I would really love to see you writing a book about Unix printing as
> except the above book about CUPS I have not
> seen a single book entirely dedicated to Unix printing. I would love to
> learn from you advantages and disadvantages of common spooling systems
> LPD, LPRng, CUPS, and PDQ. I would love to see comprehensive paper
> explaining in the details
> printing process on the printers which speak PostScript or PCL. And
> trust me I did read blue and green book for Post Scrip language and are
> read through HP technical notes regarding CPL release.
> I would love to see comprehensive compassion of various auxiliary
> filters a2ps, apsfilter, magicfilter, ifhp, foomatic and explanation how
> they work. I would love to see driver comparation ghostscrip vs
> gutenprint vs hplip.
> I would love to see lots of examples of the printcap files  which were
> used on real  *BSD machines in various situations network situation
> including heavy network printing with various groups, priorities, and
> quotas.

:-)  I don't think one person could write something like this, not
and have it be applicable.  You see, in large companies that have mixed
operating system printing, most administrators have seen the light
and just buy Postscript printers.  And more importantly, in order to
reduce their printing costs, they will buy all of the same model
printer.  They can then go buy toner cartridges by the palletload
for a lot cheaper than you or I can.  This also reduces a lot of
interdepartment jealousy and infighting because nobody has a better
printer than anyone else.  The only people who get their own printers
are people who print senstive stuff, like HR, and the secretaries for
the CEO, Chief accountant, and suchlike.

It's really only the smaller companies where you end up with a nightmare
mishmash of different makes and models of printers, where special
printer control programs like CUPS would shine.  And the admins of
most of those smaller companies generally are not that good, and
as a result they tend to avoid using complex solutions that would
simplify management - instead they like simple solutions that cause
a lot of management headaches.

> Maybe most people who use computers want them just to work but I
> personally love to know how they do it. In detail:-)

Well, just keep this in mind.  Printing is one of those things where
you can throw just a small amount of money into hardware and vastly
simplify and make easy your life.  The people who need all of the fancy
filters like the foomatic stuff are people who -mostly- have not looked
before they leapt - they have gone out and bought a cheap printer, and
ignored all the advice of buying a Postscript printer - then they come
home and figure that they can use software to get around the problem.
Those are the people who are creating the demand for the fancy software.

But consider this:

You can, today, get a color laserjet printer for about $600 that
speaks Postscript (Brother DCP-9040CN)  and will print 2,500
pages on a standard black cartridge, and 1,500 pages on each
color cartridge, and the cartridges each cost $50 so a full
cartridge replacement is $200.

On the other hand you can buy a typical inkjet color printer
for $80 that will give you maybe 100 color pages on it's inkjet
cartridge before the cartridge needs to be replaced at a cost of $50 for
a set of cartridges.  (all color and the black cartridge)

Your cost per color page for the laserjet printer is 10 cents
per page

Your cost per color page for the inkjet is 50 cents a page.

And, the inkjet has no postscript so you have to chew up your
computer CPU rasterizing the page, and if you don't print much the
inkjet will likely clog up it's print head if it sits for a month,
thus you have to toss all the cartridges and buy new ones.

So, you see, what it boils down to is the old joke about you
can go broke saving money.  It's almost impossible to run the
numbers on a color inkjet printer and come up with a page cost
that's equal or less than a decent color laserjet.  Most times
the inkjet will be many times more expensive.  And for black
and white printing it's even more rediculous - you can buy a
great, working used HP Laserjet 4+ for around $50, a Postscript
rom for about $20, refilled toner cartridges for about $20 each,
and have a page cost of less than a penny a page.

And in both cases the laser printer will produce vastly superior
printer output, and the printout will not fade or run if it gets
damp, thus be superior for archival purposes.


More information about the freebsd-questions mailing list