> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Predrag > Punosevac > Sent: Friday, February 22, 2008 1:09 AM > To: Ted Mittelstaedt; [EMAIL PROTECTED] > Subject: Re: DJ500 dead after >= 16 years. > > > Ted Mittelstaedt wrote: > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] 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 http://www.linux-foundation.org/en/OpenPrinting 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 > > tedwin2k.freebsd-corp-net-guide.com > > 192.168.1.60 > > tedsdesk.ipinc.net > > ip-port-rtr1.ipinc.net > > sunrise.ipinc.net > > 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 > which.ps > > gs -dBATCH -sDEVICE=jpeg -sOutputFile=test.jpg which.ps > > 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/colorcir.ps > > > > 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 > -dNOBATCH -dSA > > FER -sOutputFile=- - > > > > test with firefox and > > use the printer lpr -P lp-epson > > > > test PS file: /usr/local/share/ghostscript/7.07/examples/colorcir.ps > > > > > 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 > http://www.amazon.com/CUPS-Common-Printing-System-White/dp/0672321963 > 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 capabilities. 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. Ted _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
