Slashdot Mirror
CUPS 1.0 Enters The World
Well, it's basically a completely new printing system based on the Internet Printing Protocol ("IPP") that supports PostScript and non-PostScript printers and a variety of different file formats to make your life easier.
CUPS provides all of the normal printing commands ("lpr", "lp", etc.) - you still use "lpr" to print from Netscape, etc. However, these commands take on a new life with CUPS - instead of bringing up an application everytime you want to print, you can print most images, PDF files, etc. directly. CUPS figures out the type of file and runs any necessary filters to format it for the printer. Have a file that CUPS doesn't handle? No problem, just add a filter and CUPS will handle it, for any printer you have.
Printer drivers are provided for PostScript and HP PCL based printers. We're hoping that the filters provided with CUPS (including a PostScript RIP based on GNU GhostScript) will encourage independent developers and printer manufacturers like EPSON to start developing drivers that use CUPS. Only time will tell.
CUPS can be downloaded from our website at cups.org and is provided under the terms of the GNU General Public License. Commercial printer drivers based on CUPS are available from our main website. "
Be aware that printer drivers (at least for non-PS printers) often are a lot more than the implementation of the specs of the printer, and contain a fair ammount of the printer's functionality within.
These companies invest a large ammount of money into software to make their output look as good as it does. This can potentially mean complex (and patented) dithering and colour matching algorithms. Medium end printers instead move this closed code to firmware, along with a PS interpreter and enough RAM and power to handle it, or even (on higher end printers) divide their proprietary code between a dedicated print server and the rest to firmware.
Rudimentary printing is easy, but getting the most out of medium-end (?) printers ends up almost working backwards - you kinda buy the drivers and they come with the hardware to support them.
My point is not that this is good or bad, just that saying that printer vendors must open-source their drivers is to open a whole nother can of worms - is it appropriate for a company to sell closed software that runs on an open platform? I'm still not done eating my last can of worms!
Trees can't go dancing
So do them a big favor
Pretend dancing stinks!
ok, this is how it went: Xerox decided to put together Xerox PARC, the most advance computer resurch center in the world, and in doing so, hire some of the smartest computer scientists in the world. Bob Metcalfe was one of them. He was in fact so good that he was able to get a 3 month business trip to Hawaii before he even set foot in the office. On this 'business trip', he studied the way Alohanet (Hawaii's radio network) worked. And within a few months was able to come up with eathernet, the tech that we all love so dearly. The next step was to implement this new technology, and this was acomplished in the halls of Xerox PARC research center in palo alto california. There they built the first eathernet with coaxial cable, capable of acheiving 2.94 megabits per second. Xerox PARC continued to develope some other cool technologies (like the mouse and GUI) until a poor management decision gave apple the chance 'barrow' the ideas to create the Macintosh. At this point the scientists at PARC realized that their jobs were going no where, and went their own entripornorial (sp?) ways. Bob Metcalfe created 3com, the first commercial producers of eathernet cards, and most of his coworkers from Xerox became managers of their own companies too. now how was that for a long reply? from "nerds 2.0.1, a brief history of the internet"
Actually, if you read some electronics mags (Circuit Cellar did this awhile back), a hardware hacker named Don Lancaster uses printers as computational devices! You laugh, but that is what the postscript driver is, in a sense. He has written many articles about the postscript language, and even programs it directly. And he has done mathematical simultions on the printer, and ported the results back to the computer! Kind of ironic but cool stuff. Check out his page .
make world, not war
Of course, the big question is why a printer driver must needs be a trade secret.
I discussed this a little earlier, but thought of a good way to say what I mean, so this gives me the chance to have another go at it.
There are two factors that must be done to get high quality printing. There's the hardware end, which means that if you decide you want a pixel to cover v much area at position x, y, the hardware will actually be able to put the right ammount of ink there and let it dry properly.
The other factor which is as important is deciding where you WANT to put the ink to make a picture look good.
The way the printer market is currently, I would estimate that between half and a third of the R&D resources go into the second element, which is obviously going to be solved in software/firmware (resources, in terms of man-hours, not true for materials, obviously). I don't know if this is true everywhere - this is true for one high-end wide-format printer company I worked for, whose name I feel I shouldn't reveal (though I can't really think of a good reason why not).
See, here's the issue. You have a 150x150 dpi 24bpp image you want to print out on a printer that can handle 1440x720 dpi, 2bpp. Or maybe you can vary the sizes of the dots or use different densities of ink and get 8 bpp or whatever. But either way, you have to perform some deep magic to make what comes out of the paper look like what's on your screen, especially since the way the ink behaves depends on the kind of paper you're printing on. Higher end printers use CCD cameras to calibrate themselves, which also, let-me-tell-you involves some pretty clever hard things.
Consider an alternate model of the printer industry - that the printer companies are selling software bundled with a parallel port dongle which enables it to work. The reality lies at a point inbetween this and "they sell hardware".
If you're business is making and selling software, why should your code be a trade secret? Because your business model relies upon it. I am not aware of business models for pure software development which don't involved closed development somewhere or other. As far as I know most OSS business models treat development as sort of incedental. You make money selling support or something.
It *might* be possible to shift the emphasis to post-sale consumables - special paper and inks, but is this really necessary? Is there no place in this world for commercial software development except for supporting other commercial ventures?
Trees can't go dancing
So do them a big favor
Pretend dancing stinks!
Please support any problems you find to us at "cups-support@easysw.com". We *do* try to fix any problems that are reported as quickly as possible. Remember, the point of Open Source is to allow things like that to happen, making the software better! ;)
As for NULL checks, they aren't always needed, and we've tried to the checks where they aren't needed (or are duplicated) for efficiency... If you've found one missing that needs to be there, please let us know!
I print, therefore I am.
On one hand, a new printing system sounds really cool. Good that it's backwards compatible, sounds like it can provide some really neat features, but...
On the other hand, I'm not all that excited about a system that seems to encourage non-free printer drivers. Because that's what this is; the core is free, but large portions of the drivers are probably going to be proprietary.
I know some people will probably say I'm just being a whiny free software person, and maybe I am. But look at where proprietary drivers has gotten, oh, windows. You just can't depend on them. The stability of the GNU/Linux system is something we all trumpet, so why toss that out when it comes to something like your printing?
Then, let's look at experiences so far with proprietary drivers on Linux. My roommate complains all the time about his SBLive driver. It only works with some kernel versions, isn't stable, etc. I know that this isn't the same as kernel modules, but it still makes me nervous.
I'm all for new capabilities for my favorite operating system, but let's not forget the freedom that got us here in the first place. Support those manufacturers who make their specs openly available, and support free software.
--
Ian Peters
Debian comes with magicfilter package which does just that. You can send jpegs and stuff to the printer (besides plain text and postscript). So this is not entirely new concept. But I doubt how useful it is. You cannot make filters for every possible type of file. OK, so I can print pdf without Acrobat reader. Can I do the same with jpeg / gif / png / WordPerfect / as well? I'm sure it will be a cold day in hell before I'll be able to print MS Word documents that way. What I'm trying to say is that not only do you need drivers specific for every printer, but also for every file type...
I don't see what's so bad about the current printing system other then the lack of drivers. What we really need is more drivers for GhostScript.
___
If you think big enough, you'll never have to do it.
Why don't I just download the code, change it, and not tell anybody?
My Freakin Blog
CUPS and the CUPS logo are the trademark property of Easy Software Products.
Now, they've said the code is GPL, but what about the name? Will I need to send money their way if I want to advertise "NekoLinux comes with CUPS!" or something? Or are they simply protecting the name so that someone else can't also put out a program named CUPS? The later I can live with, but I'm going to get suspicious if it's so the trademark can only be used in "approved" ways without them specifying what an "approved use" is. Some clarification on their website would seem to be in order...
Oh, one other great quote:
The Internet Printing Protocol is an exciting new network protocol that provides a common set of network printing services.
I get suspicious whenever a network protocol is described as "exciting"...
Oh, and one more:
One of the many potential applications of IPP is Internet Facsimile services - you can print a document from any machine in the world to any printer in the world using IPP!
Yikes! Gods help us all...
--
"Convictions are more dangerous enemies of truth than lies."
I couldn't get it to talk to my HP LaserJet using JetDirect, even though I can easily contact it using my original printing setup and also via telnet. Oh well, it comes with the source so I guess I could hack on it.
-jwb
First, it's a real printing system, not something layered on top of LPR that doesn't let you set options.
Second, the RH filters limit the printer support to what is compiled into GhostScript; CUPS allows you to add new drivers without recompiling.
Finally, file filters are a lot easier to deal with in CUPS - it will run multiple filters as needed to get to the "destination format", while the LPR filtering mechanism only runs a single filter.
I print, therefore I am.
Well this is a great step for printing on the Unix side and a bit late if you ask me. Spending my whole life with printers, espeically high speed print servers I must say that this is really too little too late. Unix is in whole, a multi user platform made for networks, and not necesarily the everyday home user. And so most printers that interface nicely with Unix, by no surprise, are multi user, high-speed printers. Now I am going to use two printers as example to point out printer evolution on Unix platforms.
;) ) Total custom boards, nice printing interface, custom RIP software, no use of lp (lpr) anywhere.
On the small color end you have the relitively new Tektronix 780, with network features such as:
Built in HTTP server for printer management and set up, FTP server for instand Postscript file upload, SCSI and IDE HD options for job storage as well as buffering space, SNMP, DHCP, and the list goes on. Now to print to one of these small office color machines from Unix, it is recommended that you have your app create a postscript file and have the app FTP the PS file to the printer. Real simple, real fast, very effective. No configuring anything in your OS for printer ports, print servers, or anything..just the specs of your printer to make the post script file. Here at work, we have mounted the printer's HDD to a point on the network where the PS files are automatically saved and printed.
Now on the high end lets look at how Xerox has developed its high end Docutech series. I cannot say enough about the importance the original 1992 Docutech135 has meant to computers in general. It is one of the projects that led Xerox to give us the mouse, the GUI, and ethernet. Moving away from totally cutom gear now that mice and GUI's are a dime a dozen, Xerox moves the central RIP'ing precess and printer control to a nice Sun Ultra 2 (creator 2). Nice move if you ask me. Using SBus's throughput to move paper through a machine 135 times a munite, duplexing, stapleing, binding etc (controlling a printer about the size of a bus in length). Now Xerox writes a SLEW of new apps to controll this printer, and to accept jobs comming in from IPX novell netoworks, Appletalk (handling IPX and appletalk on solaris, Xerox has gonads
Point in hand.. this app, which is aimed for the home small printer user I am assuming, is nothing real majical, and for most commercial users quit insignifigant. Anyway.. sorry about the spelling grammer etc.. i am in a REAL rush.
Bort
The compile command is hidden (.SILENT in Makedefs), but any warnings and errors are displayed.
The command-line is long enough we all got sick of seeing it over and over...
The install and remove scripts are generated by the "EPM" software in the "epm" directory.
The docos don't say "make install" backs things up, only that the binary distributions do a backup...
For a LaserJet with a JetDirect, use:
lpadmin -p Printer -E -m laserjet.ppd -v socket://ip-address:9100
I print, therefore I am.
Since I hate stock lpr (who doesn't?), I recently tried a late beta of CUPS. They may have fixed all the problems I encountered, but while I was thrilled by the idea, I found the execution poor. In particular, the server had a tendency to crash with a segmentation fault whenever anything slightly strange happenned; and in the course of blundering about trying to set it up, I managed to cause many slightly strange things.
Trying to figure out why, I started looking at the source... and discovered that in many places they lack even elementary error checking. NULL pointers are passed to functions that don't check for it, system calls are made with no return value tests, etc.
Now, as I mentioned, it's quite plausible that they fixed the specific bugs I ran into (e.g. when I tried to enable a printer class, instead of a specific printer, it died). It's also possible that the code examples I saw were an aberration, and that most of the project has much better quality code.
Still, I was very taken aback; remember, this is code that is implementing a network service directly -- sloppiness often leads to security holes.
Based on this experience, I instead chose to use LPRng: http://www.astart.com/lprng/LPRng.html. It took more effort to set up, and didn't work "magically" out of the box the way CUPS did (I had to install a version of apsfilter myself, for example), but in the end it did most of the same things -- and didn't crash all the time.
Unfortunately, LPRng has "yet another wacky license", which they claim is "Open Source", but which may have restrictions on commercial use. But if you're interested in CUPS, you should check out LPRng too.
Although this is an interesting idea, it suffers from a couple of problems. The first is that it's very easy and in fact smarter to use multiple small programs to convert files to send to the print spool, instead of one large thing (see The Unix Philosophy by Mike Gancarcz for the argument with which I agree). The second is that a common printing system for UNIX does exist--but not for Linux. It's called XPRINT, and it's an extension to X11 that is used by standard CDE printing. Now, CDE isn't usually used in Linux, but CDE is _always_ used in something that's officially UNIX, because it's actually part of the UNIX 98 specs (http://www.opengroup.org). XPRINT is network-based, because it runs on top of X11. It allows use of all the X11 and X11 extension calls to draw to a printer instead of a screen. If you have an X server that supports Display Postscript, you can even just send Postscript files.
This is a little late; UNIX already has a common printing system. AFAIK, CUPS isn't network based, it's not as flexible as XPRINT, and it's not an industry standard. Granted, Linux hasn't standardised on XPRINT. But maybe it should--and maybe it would be better if you extended XFree86 to support XPRINT, and then wrote an lpr program that would use XPRINT instead, to encourage people to start using the UNIX standard, making things more interoperable with UNIX systems.
Here's the bottom few lines:
- What's the point if I can't run a program on my Solaris/Be/RiscOS/Windows/Mac/anything-with-Xlib box and print to a printer connected to my Linux box without using potentially unsupported print protocols, and do this all from Japan, printing in California?
- What's the point if there's already a common UNIX printing system?
- What's the point if I can get the same functionality and more by combining lots of small programs in creative ways?
- What's the point, full stop?
Anyway, I don't have the time, but let me just say, before anyone flames me, read the docs for XPRINT, and for that matter, X11. All the standards already exist, and they're open standards. Someone PLEASE write an XPRINT module for XFree. Then printing in Linux will be easy.
Let's end this sillyness.
There is a hidden share on the NT box called PRINTER$ (The doller sign makes it hidden, like IPC$.) In this directory, printer drivers for exported printers are put there (If you have the drivers available when you set up the machine)
The problem is most of the drivers nowadays are not OEMSETUP.INF style but SETUP.EXE style which the clients can't/won't install on their own. That is why you can get your HP laserjet to pull it's drivers, but not your HP Deskjet.
As for the Windows "Meta-language" Question, It's true there is one and it is actually rather good. I think it's called RMF (Raw Meta Format) or something. Basicly it takes the same GDI functions that you use for screen output, and writes them onto a "virtual screen" to be rendered on a printer. The virtual screen keeps track of what was done to it, and "plays it back" to the printer driver. That is why windows always knows how long you are going to have to wait for the print out - it's actually already pre-visulized the whole operation in it's head.
Let's try to make an analogy.
We're all in a church group preparing meals for the homeless and invalid. We all donate food with the understanding that it will be given away for free to anyone to asks for it. Bill Gates could get a free meal from our group, if he wants it.
Bob, a local restaurant owner, offers to give us excess food. This is perfectly fine food, but he can't use leftovers in his four-star restaurant.
Would you claim that you can't use Bob's food because he "discriminates" against his customers by charging them for their meals? Or would you recognize that Bob isn't a single-dimensional caricature of a wild-eyed zealot and he doesn't have to follow an arbitrary standard in all things? Hell, would you even consider the possibility that Bob really wants to serve meals to the homeless and his restaurant is simply a way to acquire and pay for the high quality food for the homeless?
Speaking for myself, my reaction when seeing responses like yours is that the GPL isn't worth the trouble. IIRC the BSD license is still DSFG free but is a lot more tolerant of pragmatic coexistence with unenlightened businesses.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Patrick Barrett
Yebyen@adelphia.net
Restating the obvious since nineteen aught five.
CUPS uses filters for various filetypes. So hopefully I can get better quality for massive graphics than I can with postscript which basically vector-based from what I understand.
If CUPS is better and the license is right, then it should become the standard for GNU systems.
I am not sure about the Internet Printing thing. Isn't that what Xerox is doing? I guess it would be neat to print my file at my Uncle's house... kind of like faxing, huh?
The internet is making everything weird.
--