Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?
Unix Operating Systems Software

CUPS 1.0 Enters The World 265

Michael Sweet writes "Well, it's taken us long enough (nearly 2 years since we started the project), but the Common UNIX Printing System, or "CUPS", is finally out of beta and ready to replace all those 1970's line printer spoolers masquerading as printing systems. What is CUPS, you ask?

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 and is provided under the terms of the GNU General Public License. Commercial printer drivers based on CUPS are available from our main website. "

This discussion has been archived. No new comments can be posted.

CUPS 1.0 Enters The World

Comments Filter:
  • 1) Windows has no printing design. Unless it's ascii, every program has to have its own filter for output to the printer driver. 2) Ghostscript acts like a super-filter; postscript in and hundreds of supported printers out. 3) You have to replace lpr with LPRng to pass arguments thru to ghostscript. Causes problems on RH which I haven't fixed yet. LPRng is the modern printing system you may be missing.
  • What's the difference between CUPS and lprng+magicfilter?
  • They license out their Postscript name and technologies. The reason Mac OS x is supposedly still delayed is that the drawing API was based on Display Postscript. Besides being slow (from what I heard), Adobe wanted a lot of money for them to use Display Postscript. So they went and started work on a new graphics API (which, funnily enough, sounds like Display PDF)
  • by Anonymous Coward
    DFSG Analysis of CUPS
    1. Free Redistribution No. Cups does NOT allow the name CUPS to be used in any redistribution of the software. Trademark law covers variations of a name as well. Therefore, the product known as CUPS is not redistributable as CUPS.
    2. Source Code
    Yes, source code is provided. 3. Derived Works Dependant on whether or not the work is non-free. For this assessment, we will assume that all modifications are free (in compliance with GPL. Yes.
    4. Integrity of the source No restrictions on this aspect. Yes, it passes.
    5. No discrimination against persons or groups The release does not violate this clause.
    6. No Discrimination against fields of endeavor None, however the moment a binary only patch is made to the official GPL'd package, the entire GPL'dness of the product is violated.
    7. Distribution of License The program is NOT REDISTRIBUTABLE under the same license , as a different license exists for those who wish to remain closed sourced in API development
    8. Not a debian specific license License is blanket.
    9. License must not contaminate software License does not contaminate. 10. Example licenses License is GPL

    Analysis: While this does tread on shaky areas of the GPL, it is clear that this program does violate the DFSG and the Debian Social Contract. The point of contention lies with the 7th and 1st law of the DFSG, where the 1st law is conflicted by disallowing of the same name (which covers blanketed through the system, much like a patent) of the subsequent patches, and the 7th law, which states that the PROGRAM must be redistributable under the same license. The inclusion of the Binary license and the program's redistribution under this seperate, GPL exclusive license violates the policy of the Debian social contract. Jarrod K. Henry
  • by Anonymous Coward
    Good. IPP-based fax sounds like an extraordinarily bad idea to me. It'll be great for about as long as it takes spammers to figure out how to exploit it, and be useless after that.

    As far as I know, there are laws in the United States preventing the facsimile of unsolicited advertisements. I don't know if this law only applies to telephone networks, but it seems to me that government types wouldn't bother to make such a distinction.

    Summary: I think net-based spam faxes would probably be prohibited by this law (if it exists in the first place).

    chahast at pangaea dot dhs dot org

  • AFAIK, X itself doesn't provide outlines, ligature or kerning information, and some other junk. If X doesn't provide it, I'd doubt that xprint would, and if so, it's deficient. (Think for a moment why almost no linux word processor uses X fonts for much of anything. It's not because they're stupid.)
  • Yes, that is true, and that is pretty much what happens. The most common intermediate format is PostScript; most of the magicfilter stuff convert to PostScript or PPM and from there to the printer-native format, usually using GhostScript.

    Using magicfilter, to print, say, a JPEG on a DeskJet 550C you do the following sets of conversions:

    JPEG -> PPM (using djpeg)
    PPM -> PostScript (using ppmtops)
    PostScript -> dj550c (using GhostScript)

    Magicfilter do these automatically by looking at the output for each conversion stage.
  • Hmmm... there may be a fairly serious problem with this. Interestingly enough, reminds me exactly of the /. article earlier today on the proposed TGPL (transitional GPL... don't have a link here, sorry). Anyway, the problem I see is that these people plan on selling proprietary versions of their copyrighted software... fine, no problem with that. But they are distributing their software under the GPL -- presumably this means that outside developers (GPL hackers) will contribute work, bug fixing and new features to the CUPS code base. Now, I have trouble believing that these changes, improvements and new features won't get folded back into the main CUPS code base. But are they then going to relicense versions of this software, containing code that they *don't* hold copyright to, which has been "imprisoned" as closed source software? This would be clear violation of the GPL, unless the submitters give explicit permission for this to be done (the patches written and submitted would otherwise, presumably be GPLed). Perhaps this really would more properly call for the TGPL, afterall, which would allow for a business model such as this, and allow submitters of patches and new work on the CUPS code to choose either GPL or TGPL for their own code. Anyway, just some thoughts about some possible problematic issues with this practice. Hope I'm just misunderstanding something here, but I kinda doubt it.
  • Go look at any of the FSF's projects. You can't get code in GCC without turning the rights over to the FSF
  • Distribute or sell printer drivers and filters that use the CUPS API so long as source code is made available under the GPL.

    Does that mean *all* printer drivers have to be GPL? What if the company doesn't want to release the source? I don't see how it would encourage companies to release more printer drivers.

  • You're thinking of EMF, Enhanced Meta-File. The unfortunate thing there is that it does not play well with PCL on the higher-end LaserJet printers. At least, in all of my testing, it didn't.

    Otherwise, you're quite correct.

    By the way, one of the annoying thing about Windows client printing is that the drivers are pulled down with each print job. You'd think someone would come up with some way of checking the version or something to save network traffic... oh well!

    QDMerge [] 0.21!
  • Well, I just managed to answer my own question by reading the FAQs on Here's the relevant portion: Can I Contribute Code/Drivers to CUPS? Certainly. If you want to retain ownership of the code, filters and drivers can be contributed to the CUPS Bazaar. To contribute code to the base CUPS distribution, please contact us via email at Because we also provide CUPS under a binary distribution license, we will require that all ownership of the code be transferred to Easy Software Products, or that Easy Software Products be granted unlimited distribution rights to the code (possibly via payment of a fee to the contributor.) Code contributed to the base CUPS distribution must conform to the coding and documentation standards outlined in the Configuration Management Plan. In addition, a short outline of the changes and/or added functions must be provided so that we can update the CUPS documentation accurately.
  • Just a heads up here, for those who want to replace NT servers with SAMBA, Jetdirect internal and external units will not function for longer than 5 minutes with your average (redhat) lpr daemon

    I'd be interested to know what you are doing to screw things up so horribly. I have used redhat from v4.2 to v6.0 with no problems whatsoever. This is with 1 and 3 port external JetDirects, and the internal JetDirects in HP4 series, HP5 series and HP4000 series printers. That sure does seem to cover most of what is currently in use. For more than just 5 minutes even. I have printed whole users manuals (300-400 pages) all at once with these tools.
  • I dont know, though. Although simplifying things is almost always a good thing, I'm concerned that this is just going to complicate an already complicated field. I am assuming it is completely backward compatable, is it?

    What I don't know is, how widely supported is this? Has an companies with linux or unix distro's jumped on the bandwagon? I guess maybe we should take a wait and see approach.

    -- Moondog
  • The early Xerox networks ran XNS (Xerox Network Service?)

    Which was the basis for the Novell IPX protocol, just to add to the things that Xerox never made any money from.
  • Sticks!!! You had sticks?!?!?! We had to scratch the dirt with our finger nails.
  • by Cuthalion ( 65550 ) on Friday October 01, 1999 @07:40PM (#1643835) Homepage
    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!

  • Well in a pretty short period of time, the average PC monitor has gone from about 60 dpi to 100 dpi+. Eventually we're going to have display technology which gives us "laser print" resolution (200-300 dpi). Maybe then it will become obvious to the overlords of the X Window System (the commercial UNIX companies) that X's font handling and general pixel-dependancy is broken.
  • Well, CUPS is pretty useless to me, since it apparently does not accept LPD connections from other print servers. I dug through all their documentation, and as far as I can tell, if this is supported, it's not documented. And, CUPS uninstalls your stock lp* during installation. So, unless I install CUPS on every *NIX box on my network, I can't print to CUPS from *NIX?

    According to the Admin docs, CUPS only listens on the IPP port, and you can set it up to listen to the HTTP port. No mention of LPD, other than to say it can SEND jobs via LPD.

    By the way, I am near the end of a (so far) extremely successful implementation of LPRng in a commercial environment. I had a brief correspondence with Patrick Powell, author and current maintainer of LPRng, and he has assured me that I can use LPRng with no charge in a commercial environment, but I haven't seen the actual license... all it says in the README is "Released under the GPL for use in non-commercial environments," which is pretty vague for my taste.

    Auditing and dentistry are excellent career choices for people who don't
  • perhaps we should instead be looking for printer drivers that accept something like HTML, and render it as they see fit for the target device.

    Like, uhh, PostScript?
  • The only problem I have with the current printing
    system is print quality. Documents and web pages
    print pretty good. But if I want photo quality
    output, i have to boot to windows.

    This is most uncool. Printing graphics in linux on my epson stylus 600 is awful.
  • I can only say..
    UNIX printing has always struck me as a total relic. I can see how it was appropriate years ago when everyone printed text and printers didn't need drivers, etc., but in today's printing world something more advanced was needed.

    Hopefully, this is it

  • I wasn't saying that NDA printer drivers should or would be part of the GPL'd version. Some distributions would choose to ship all the free (beer) printer drivers with the free (speech) version of the program, some wouldn't. This would not compromise the free version of the program.

    As far as not being able to called a forked version of CUPS CUPS, it's their choice and it doesn't violate the DFSG. They want to retain control of the product called "CUPS", and that's their right.

    Another example of this is the Open Sound System. The linux kernel ships with a version of OSS called OSS/Lite. OSS/Lite is the GPL version of OSS, which isn't free in any sense of the word. However neither the existance of OSS, nor the existance of binary only drivers for OSS/Lite mean that Debian can't ship OSS/Lite. I have a SBLive on my computer, and as you may know, the SBlive driver is binary only. For obvious reasons, Debian does not include the driver to this card as part of it's distribution. However I was able to download this driver and use it with the kernel that ships with Debian because the OSS/Lite code is GPL and therefore DFSG compliant.

    To use your example of QT, the QPL is DFSG compliant. KDE could not be included in Debian because there was no free version of QT. There was a commercial version and there was a pseudo open source version. There was no version of QT which met their standards. However, when QT 2.0 came out, it was released under a license which was basically the GPL with a clause saying you can pay Troll Tech to write commercial programs, and it was accepted into Debian. Take a look at Debian's ftp server if you don't believe me. You will find Qt [] right there.

  • For every lab I administer, I would MUCH rather have proprietary and/or "quirky" drivers to the complete lack of drivers that are out there now.

    You may say that windows has buggy drivers, but there's not a current desktop printer out there that won't work under win32. :)

  • So, we're out with CUPS. Now if we could just get Adobe to give us some Linux versions of their tools, life might be (almost) perfect.

  • Another example - most of the current Lexmark Laser printers (1625, etc.) not only have an IP stack, not only support jet-direct protocol (port 9100), not only support tftp'ing files to the printer, not only support ftp'ing files to the print, but they have built in lpd support - that is, you can establish a remote queue definition pointing directly to the printer (IP = address of printer, queue = raw1). And the 1625 is a fairly low-end printer.
  • The only serious problem with Linux printing is the lack of ghostscript drivers for some printers... but since this CUPS only seems to have ps and pcl drivers, we'll need to use ghostscript for 90% of it's printer support for some time.

    AFAIK most printers who isn't a matrix printer or similair (line printers and such) uses PCL and/or PS.

    And LPD/LPR is a pain to setup. Printing is one of Linux's real problem before it goes out to the newbies who wants to run it.
  • You should know that the copyright holder *is* the licensor and thus has the power to do whatever they want with respect to having different multiply licensed versions of software. Only if they *take* code others have contributed to the GPL version (i.e. code they don't hold the copyright to) and try to roll that into their binary version would they be violating the GPL. If you read their web site, they clearly don't plan on doing this. There will just be a forked GPL amalgamated version, I would imagine and a separate version containing only code they hold copyright to (and thus can license in any way they please). As much as some of this may violate the *spirit* of free software, it is all within their rights, and remember that as this is GPLed software, you can take the code and do any damned thing you want with it (i.e. maintain your own GPL only version for bazaar style driver development of fully free software).
  • I've never heard about this until just now. I have to say, the printing situation was getting in the way of my Linux advocacy. Even though the driver system on WinXX is pretty braindead (drivers must be on all the client machines instead of sending the device independent data to the print server! Geez, what genius thought of that?!?!) the support is good, and odds are you can print on whatever noname printer you have on your desk.

    Whenever someone newly installs Linux, and then asks me about setting up the printer, I ask, ``Does it do PostScript?'' *Blank stare*, then I start to whistle and change the subject.

    All that's changed now!

  • > So, we're out with CUPS. Now if we could just
    > get Adobe to give us some Linux versions of
    > their tools, life might be (almost) perfect.

    Adobe tools suck rocks. Their acroread is poorly
    implemented in a lot of ways. They patent their
    standards (like pdf) to prevent others from being
    able to make pdfs without paying the man.

    They embrace and extend their proprietary standards (PS and PDF) to keep open source tools
    from being able to work with full functionality.

    I do a lot of PS hacking with open source tools,
    and Adobe has about the worst attitude towards
    open source PS hackers as you can get.

  • I remember running a filter suite called "magickfilter" (or something spelling variation of that) back in about 1994 on my slackware linux box. You could do "lpr pr0n.gif" and it worked flawlessly on my HP LaserJet. It was also very easy to set up.

    One thing it did not have, however, was the ability to have custom printer filters applied by a printer server. In other words, I wanted to be able to send the job from a client workstation to a central printer server, have a custom PostScript-based coverpage (with the printee's username on it) prepended to the print job. Since it used plain ole lpd, this was not possible. It was only possible to do printer filters on the client workstation, not the print server. We wanted to print out a cool coverpage with our schools logo and the username in a nice helvetica font but could never find something to do the job. Perhaps CUPS has this figured out?

    It's very unfortunate that people still insist on printing stuff out, but if they have to do it, might as well do it right! chris
  • by Anonymous Coward
    I've been using PPR ( for a while now, and it does an excellent job. It seems to support all the things that modern print spoolers should (media types, printer grouping, charging, etc.), it supports SMB and Appletalk printing, knows about using ghostscript for filtering and printing to LaserJets and other evil non-postscript printers, magically filters (and scales appropriately) JPG, PPM, PDF, TIFF, TeX, text, and heaps of other stuff (it uses netpbm). It can receive jobs from appletalk, smb, and lpr. It can know what paper bins a printer has just by looking at the PPD. It doesn't know about IPP yet, but it does everything a good print system should do, and doesn't have the kludgey feel that LPR tends to have. And it is free software. -Daniel.
  • It's not Linux, its most likely the print filter you're using that was causing you headaches. You just gave up on using Linux too quickly. Other distributions such as Debian and Caldera install LPRng by default.

    Use LPRng rather than Redhat's stock lpd - for a serious print server you want all the extra features LPRng offers, such as being able to send postscript directly to port 9100 on the Jetdirect card, web management (with lpinfo), the ability to have one printcap file that works across all print servers, support for installation on most commercial Unices, etc... LPRng comes on the Applications CD that comes with RedHat, is GPL'd for non-commercial uses, and is free for commercial implementations, but I'm unsure of other restrictions besides price for commercial uses. Anyway, if the license was good enough for the Debian group, it's good enough for me.

    ________________________________________________ _______________

    Auditing and dentistry are excellent career choices for people who don't
  • Yeah, if you can use a printer that supports Postscript directly rather than having to use Ghostscript, it will work better.

    Auditing and dentistry are excellent career choices for people who don't
  • Absolutely not. See their FAQ on this at You have to give it to them and give them ownership of it before it becomes their property (i.e. you must consent to transfer your copyright to them). I certainly wouldn't do that for any significant chunk of code I had written. They also have what they call the CUPS bazaar at, basically just a friendly database of patches, filters, or whatever that are not part of the base distribution. Anyway, the point is there's nothing here stopping somebody from forking a GPL only version off from this and taking GPL only patches from people and building it into a better CUPS. In fact, if there's enough interest in the community I could definitely see this happening. The people at Easy Software Products might not let them use the CUPS name, but it's not like CUPS has market share or name recognition at this point. Anyway, my point is that these people may not Get It (TM), but they aren't so stupid as to steal other people's code against their will. Or else, goodbye community support, hello forked GPL version and no more Easy Software Products. :)
  • by Anonymous Coward
    I had a problem like that with some networked printers. The solution I found was to add an "empty: field :if=/bin/cat: for every networked printer as in: hp4000:\ :sd=/var/spool/lpd/hp4000:\ :mx#0:\ :sh:\ :rm=hp4000.printer.ip:\ :if=/bin/cat: I don't know about your case, but this might help
  • On the other hand, I'm not all that excited about a system that seems to encourage non-free printer drivers.

    On a historical, semi-ironical note, wasn't it a proprietary printer driver that sent RMS on the GNU trip in the early 80's? :-)


  • Seems to me it'd be pretty straightfoward to implement the same thing in UNIX. Just set up an X server to emit PostScript code or HPGL or whatever

    That's what the XPRINT extension supports; it then hands the resulting output to whatever print spooler system you have.

  • by Anonymous Coward on Friday October 01, 1999 @09:25PM (#1643874)
    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"
  • Windows uses the same API for screen and printer output.

    The XPRINT extension for X11R6.1 and later follows a similar model - there are some added calls to start and end pages, select a particular printer, etc., but most of the drawing can be done with Xlib calls (or, if one can get an some toolkit for X to use a particular X display for particular calls, with higher-level toolkit calls)

    The GDI subsystem sends the drawing primitives to the driver corresponding to the selected device context which is responsible for converting these to whatever commands needed for your particular hardware. The output then is send to the spooler.

    XPRINT is also similar, in that the X Print server to which you connect generates PCL, PostScript, or whatever page description language, and hands it to your system's print spooler.

    UNIX print spooler systems may also have their own mechanisms for turning various file formats into commands for a particular printer, e.g. filters to turn PostScript into rasters for printers that don't support PostScript.

    In case of network printers, the actual mapping of your job to a remote printer is done somewhere at the spooler level. i.e., below the printer driver. That has two implications:
    1. Printer driver must be installed on each client machine. When you install a remote printer, Windows actually copies driver files from the server machine to yours.
    2. The actual data sent on the network are binary printer commands, not any higher level primitives.

    If the X Print server you connect to is on a local machine, printing would work that way with XPRINT, although there's no mechanism for automatically copying printer drivers from the server (it may, after all, not be running the same OS as your machine, or, even if it is, it may not have the same instruction set; how well does that copied print driver stuff work with, say, an Alpha server running NT and x86 clients running NT or W9x?).

    If the server's running an X Print server, it could also be done by connecting to an X Print server on that machine, and sending it the X and XPRINT requests to draw stuff over the wire.

  • The problem isn't with RedHat's "lpr" implementation but with certain older versions of the JetDirect firmware. See, for example, this ISS Security Advisory [] which describes the problem, and related DOS attacks, in detail.

    Newer versions of the JetDirect firmware have working TCP/IP stacks, which may explain all the wise-asses who wonder what "you're doing wrong".

    The easiest solution for those of us unlucky enough to be saddled with bad firmware is to switch to LPRng and, following the advice in the LPRng-HOWTO, use the printer's port 9100 as a direct link to the print engine.

    At our site, we had no end of problems with HP printers crashing, locking up, and loosing jobs whenever two people tried to print at once. One day, I bit the LPRng bullet (and even installed "magicfilter" while I was at it). The configuration was a little work, but it was worth the effort. Finally, we have a printing system supporting Linux clients (using both LPRng and legacy "lpr") and Windows clients (via a Samba server acting as an LPRng client) that seems to work flawlessly.

    Of course, all our printers are PostScript, so we don't have to worry so much about this newfangled CUPS stuff.

  • But he wasn't talking about Linux. He was talking about CUPS, an application. The most stable kernel in the world won't make a difference for a crappy application running on it. He didn't say the system went down, just the print-system, the application, there's a difference.

    Besides, I fail to see how CUPS is much different from the rhs_printfilters shipped with every RedHat, or the similar filters Debian use. You can print almost anything directly, if you don't care about having some control with how eg. a TIFF is put on your paper (functionality which the Gimp will easily provide).

    LPRng is nice though. It's much more fault tolerant than the standard lpr package. It puts a lot of effort into working with printers that aren't exactly acting as the RFC suggests. Too bad about the crappy licence.

  • Postscript is owned by Adobe, and they charge a fairly hefty fee for every printer you ship with postscript installed. Thus, low- and mid-end printers can't use postscript as the fee would drive the price per unit too high.

    I suppose printers could use ghostscript, but for the unwashed masses, being a "ghostscript printer" won't be a convincing selling point.
  • While I know that lots of *nix's these days (IRIX, Solaris, RedHat) do everything in their power to make you run a GUI on the server, I still see that as a really bad move.

    Anybody know whether it's possible to run an X Print server on a headless machine (i.e., a machine with no display on which an X display server could draw)?

    Why should I run X on my print server?

    XPRINT doesn't require you to do that, as far as I can tell; all an X Print server does is accept X drawing requests, generate page description language output to draw that stuff on paper, and then hand to the print spooler system a file containing that output. You could, as far as I can tell, run the X Print server on your desktop machine, and have it hand the file to the spooler system, which could send it to the print server.

    If you're running the program doing the printing on a server, that program would have to talk to an X Print server somewhere, possibly on that machine, or possible on some other machine.

  • by Anonymous Coward
    You cannot imagine the HOURS I spend while working in Tech Support dealing with printing from Mac's and PC's. easy printing is ESSENTIAL for an OS to be used on the business desktop, and it's about time Unix had decent support.
  • by wass ( 72082 ) on Friday October 01, 1999 @02:22PM (#1643929)
    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 [].
  • Just go to their download page. The source is listed in the select box along with the binary platform versions - jwb
  • Um, that would be a "WinPrinter," and we don't want no stinking WinPrinters in Linux!

    Uh, then buy a postscript printer, where they move the closed code to firmware.

    I suppose that last can of worms was Open Source operating systems or applications? If you're not done with that one yet I can see why you have the opinion you do. Give it time, you may learn the benefits of OSS some day...

    I quite intentionally refrained from expressing my opinion regarding open source, because I wasn't explaining why I don't write fully open source printer drivers.

  • by Cuthalion ( 65550 ) on Saturday October 02, 1999 @04:54PM (#1643942) Homepage
    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?

  • by printman ( 54032 ) on Saturday October 02, 1999 @04:11AM (#1643944) Homepage
    Please support any problems you find to us at "". 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!
  • This is an intersting project, and in the long run I think that having a more device-independent framework for printing will benefit the Unix community.

    I do have one question, though. Instead of distributing an enormous archive of their custom GhostScript, why don't they just contribute their patches back to the GhostScript folks? I would like to test this, but frankly my own printing setup is working just fine, and I don't want to replace the whole thing en masse.


  • > THat's what happened with QT , and why to this DAY KDE is still considered non-free.

    Except by RMS, who has personally called it free software.

    stupid git.
  • by itp ( 6424 ) on Friday October 01, 1999 @02:28PM (#1643950)
    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
  • (offtopic) Rather like some of the old Atari (or it might have been Amiga) demos that ran the main code loop on the CPU, and used the tiny processor in the keyboard to do rasterization, because, well, it was programmable. :)

    (more ontopic) This is nice to see, though -- any modern remake of lpr/lpd would be an improvement, and in particular seems a good example of the potential for coexistence between commercial for-profit software and free software -- the architecture is free, and specialized drivers for individual printers can be had for cost. Might not be suitable for home and hackerish uses in that respect, but business environments would lap it up.

  • It was always "DIX Ethernet"

    Indeed? Digital and Intel were involved in the original 3Mb Ethernet? Or were they just involved in producing the 10Mb standard? (Did Xerox have 10Mb Ethernet before the DIX standard came out?)

    And it was Boggs and Metcalfe

    Yup, as I said.

  • by RelliK ( 4466 ) on Friday October 01, 1999 @02:34PM (#1643956)
    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.
  • by chuck ( 477 ) on Friday October 01, 1999 @02:37PM (#1643958) Homepage
    This is very unusual:
    Easy Software Products also sells rights to the CUPS source code under a binary distribution license for vendors that are unable to release source code for their drivers or additions and modifications to CUPS under the GPL. For pricing information please contact us at:
    So, let me get this straight... If I want to take their GPL'ed code, and make proprietary changes to it, I have to pay them a license fee? I seriously hope I'm misunderstanding this. I mean, they're the copyright holder, so they can do whatever they want. It doesn't even conflict with the GPL, so far as I can tell, but it just seems... weird. Even weirder, I bet you more than one company is going to do it.

    Why don't I just download the code, change it, and not tell anybody?

  • by osu-neko ( 2604 ) on Friday October 01, 1999 @02:44PM (#1643961)
    From their website:

    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...


  • by Jeffrey Baker ( 6191 ) on Friday October 01, 1999 @02:45PM (#1643968)
    I took the plunge and installed it, so now I can make a report.
    • Compile went fine, but I dislike build systems that don't show the compiler's output. This is open-source, folks. If you show the compiler output maybe some hacker will send a patch to fix your warnings.
    • The installation script cups.install is missing from the distribution, and
    • The uninstallation script is also missing.
    • In direct conflict with the README.txt file, The make install does not backup your current printing system!
    • After I installed it, it didn't work

    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.


  • by printman ( 54032 ) on Friday October 01, 1999 @02:51PM (#1643976) Homepage
    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.
  • We've pretty much gutted the GS 4.03 distribution (all of the old drivers are gone, as is the normal command-line interface) We've toyed with distributing patches for GS, but that makes downloading less convenient...
  • by bortbox ( 77540 ) on Friday October 01, 1999 @02:57PM (#1643981)
    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.

    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 ;) ) Total custom boards, nice printing interface, custom RIP software, no use of lp (lpr) anywhere.

    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.
  • by printman ( 54032 ) on Friday October 01, 1999 @02:58PM (#1643983) Homepage
    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
  • This is very unusual:
    Actually, it's not that unusual. That's the way qt licensing has worked for some time now, and it was debated endlessly a while back. ;)

    After going over the FAQ, I think cups looks like a decent system. It improves the way that printing works, allows for free drivers to be written (they've even got a database for them) and if you're the type who "needs it for REAL work", you can get the proprietary drivers to do it with. Sort of like XFree86's relation to AcceleratedX, but in reverse (since the cups guys are giving the free infrastructure to base everything on) That's a pretty kind thing of a proprietary-software making company to do. Usually those just find ways to lock you in (eg., EVERY system on the network needs to buy our proprietary driver! or.. If you use our package, you can only use OUR drivers!) etc.

  • I discussed this with a member of the stampede linux project once before. It seemed like a great feature to add to our distribution. We were slightly worried about the AFPL, which is similar to the original QT license. Luckily, we're not constrained by the same guidelines as Debian, and can provide this, but I am more concerned about this product. Can someone give a better explanation of the APSL license so we can figure out how or if to include it?

    The relevant clause is this:
    CUPS is available under the terms of the Aladdin Free Public License, which means that it is basically free except for commercial distribution.(1)

    Does that mean that Cheapbytes wouldn't be able to sell a Stampede CD that contained it? If so, this is going to have a hard time being accepted in the major distros.

    (1) I don't think this is the legal text, but the jist, as provided by
  • by printman ( 54032 ) on Friday October 01, 1999 @03:03PM (#1643987) Homepage
    Since the CUPS API library is GPL'd, and you need to link to it to get access to the PPD and raster file stuff to write a driver, printer vendors have two options - release an open source driver or license CUPS from us so they can distribute binaries. I'm hoping they do the former (open source driver)...
  • This definitely sounds like an improvement over existing Unix printing systems, but I'm not clear on whether it's going to be all that helpful on the client side.

    Modern printing is more than just throwing a stream of data at a printer. When you set up printing in a Windows app, the driver lets you configure dozens of printer-specific options (paper trays, paper types, duplex, halftone settings, etc.) through a series of dialogs.

    If CUPS requires a typical user to pass a bunch of command-line options to lp when he wants to run an unusual print job, then it's not going to be the least bit of help at getting Linux/Unix onto more desktops. The ability to print documents without invoking the application is nice, but hardly important to the people who do most of the printing in this world.

    I haven't actually tried CUPS yet, so I may be totally off-base here. Actually, I hope I'm wrong, because printing is one of my biggest obstacles to getting Linux into non-geek environments.

  • by printman ( 54032 ) on Friday October 01, 1999 @03:06PM (#1643989) Homepage
    No, that's not how trademarks work.

    ANYONE can use a trademark name so long as they credit the owner. The purpose of a trademark is to protect the integrity of a name. We're doing that for CUPS for the same reason that Linus trademarked Linux...

    As for IPP, look at the available docos on the net. Make your own decision.

    As for IPP-based fax, CUPS doesn't come enabled for that. Security is a very big deal for us.
  • by printman ( 54032 ) on Friday October 01, 1999 @03:13PM (#1643994) Homepage
    The main difference between the magic filter stuff and CUPS is that CUPS supports things like *job options*, and the magic filters are still only 1 level "deep". CUPS can run multiple filters to get from file type A to B.

    As for MS Word, we're looking at adapting some of the available conversion programs to work with CUPS.

    Finally, how big do you want GhostScript to get? What if you have a dozen printers and are printing to them all at the same time? Also, GhostScript stinks once you start feeding it images; separating the drivers allows us to write other RIPs like our image file RIP to make printing faster/more efficient.
  • by egnor ( 14038 ) on Friday October 01, 1999 @03:19PM (#1643996) Homepage
    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: []. 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.
  • From []
    How Is CUPS Licensed?

    CUPS is provided under the GNU General Public License, Version 2. A copy of this license follows this introduction. For those not familiar with the GNU General Public License, the license basically allows you to:

    Use the CUPS software at no charge.
    Distribute verbatim copies of the software in source or binary form.
    Sell verbatim copies of the software for a media fee, or sell support for the software.
    Distribute or sell printer drivers and filters that use the CUPS API so long as source code is made available under the GPL.

    What this license does not allow you to do is make changes or add features to CUPS and then sell a binary distribution without source code. You have to provide source for any new drivers, changes, or additions to the software, and all code must be provided under the GPL.

    It says the same thing in the LICENSE.txt file in their source distribution. Where did you see the other license? Perhaps they saw your message and changed it real quick? ;) In any case, that they allow GPL distro *or* for-pay proprietary redistribution does not prevent any Linux distro from use it.
  • First, it's a real printing system, not something layered on top of LPR that doesn't let you set options.

    Whew, glad I can finally stop printing everything with a fake printing system now.

    What options does CUPS offer that you can't put in a postscript file or pass to lpr? Granted the feedback could be better than "the printer isn't working" when something goes wrong, but that's about all I'd like to improve.

    Second, the RH filters limit the printer support to what is compiled into GhostScript; CUPS allows you to add new drivers without recompiling.

    This is a technical plus, but not a huge practical plus. GS 5.10 takes up a little over a meg on my hard drive, and is updateable with one command.

    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.

    This is factually incorrect. Take a look at the print filters system in Red Hat (or Debian, or anyone else) sometime. If there's a jpgtopnm filter and a pnmtops filter installed, you don't need a jpgtops filter to be able to print through ghostscript.

    The only serious problem with Linux printing is the lack of ghostscript drivers for some printers... but since this CUPS only seems to have ps and pcl drivers, we'll need to use ghostscript for 90% of it's printer support for some time.

    Granted, CUPS looks like an improvement, but not a huge one.
  • Good. IPP-based fax sounds like an extraordinarily bad idea to me. It'll be great for about as long as it takes spammers to figure out how to exploit it, and be useless after that.

    That's what passwords and allow/deny filters are for. Just put the people you want to fax to/from in your allow/deny, or give your friends the password for your printserver... voila! phoneless faxing!
  • Look again: from MS Technet asp?target= online/Content/Complete/windows/winnt/Winntas/manu als/concept/xcp05.htm

    Windows NT supports true remote printing. When Windows NT and Windows 95 clients connect to a correctly configured Windows NT print server, the printer driver is automatically installed on the client computer. If you install a newer printer driver on the server, Windows NT client computers automatically download the newer printer driver. However, if you install a newer printer driver for Windows 95 clients on a print server, users running Windows 95 must manually update the printer driver to have the newer version copied to their computers

    You just don't *see* it happen.

  • Yes, well I did precisely that, and the printers.conf file is updated fine. In fact, when I print the jobs are spooled on the disk and logged in the error and access logs. It's just that nothing ever gets to the printer!

    Sigh. If I'm really interested, I'll join your mailing list.


  • I haven't read the license in question, but it sounds a lot like what I plan to use on the bigger projects that my company produces. Assuming I ever get anything out of the door. (Alternating between paying contracts and OSS projects sounded so easy a year ago... :-)

    You can use the code, as is, for free.

    You can modify the code, for free, provided you "pay me" by releasing your changes back into the community. (If the changes are substantial and worth folding into the main tree, I'll license the changes from you so I can re-release them under the terms below.) It's important to note that this is a pure GPL license.

    If you really, really want to keep your changes "secret," you can pay me in hard cash instead of published code. I prefer code. The licensing rates will make it clear that I prefer code. But if you're unwilling to consider a GPL license, I'll work with you if that's what it takes to keep you from using a totally closed solution. I'm tempted to call it "BSD-for-a-fee" licensing, but that would simply confuse people. :-)

    In any case, I don't expect to make money from my OSS projects.... but I *do* expect to make contacts for bigger projects and higher rates. Even without any projects getting beyond early beta, I've found the experience of working full-time on a project has already paid profound dividends on my current (for-profit) job.
  • by Anonymous Coward on Friday October 01, 1999 @03:37PM (#1644013)
    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 ( 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.
  • by wilkinsm ( 13507 ) on Friday October 01, 1999 @05:04PM (#1644017)
    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.
  • by coyote-san ( 38515 ) on Friday October 01, 1999 @05:08PM (#1644019)
    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.
  • It doesn't help apps determine what fonts are ok, it doesn't help them create the output, it doesn't give them a working font model, font metrics, the kind of info in afm files, etc.

    To what extent does the XPRINT extension provide that (at least for X applications), and in what ways doesn't it provide that? ("In what ways doesn't it provide that" could include ways in which X itself is deficient - and which might be ways in which apps don't have good enough display support as well.)

    That'd work, of course, only if you have an X Print Server available, which not all UNIX systems necessarily do.

  • I think a much more important thing we should focus is on ipp. I read the RFC, and am not sure if things are being done right. For instance, if you send a postscript job to the printer, it will have inline information about color, media size, simplex or duplex printing.. How will the printer decide if it uses the data on the ps stream or given to the ipp server? also, why should people on win32 machnes have to download and install a printer driver? couldn't windows/macs/unix produce a generic file, whithout the information set via ipp, and send it gzipped to the printer?

    Also, could someone point me to a link which describes the win32 printing system? How does applications send data to the printer driver? Is it a generic format? If so, couldn't this data be passed over the network to a remote printer driver?

    I think there is too much things to be improved in this area.. but my knowledge on printing systems is close to null..
  • That's nothing, pal!

    When I was working at Cook County Hospital as a programmer trainee, I was asked to print their inventory proof sheet for the daily transactions. It was about 50 pages of 132-column text on fanfold paper (remember that?) By mistake, I coded:

    // PRINTER ... blablabla...,SYSOUT=B

    instead of whatever the Hell I was suppoed to do. I remember that SYSOUT because, about an hour later, I got a call from Operations:

    "'scuse me, sir, but we have 6 boxes of punched-cards you generated just now. What do you want us to do with them?"

    "I'll call you back later," I said.

    I told my trainer. He laughed for about 20 minutes, then said:

    "You'd better not call them back. I'll take care of it for you."

    I'm surprised they didn't make me put all the confetti back in...
  • Okay, please don't get this mixed up. CUPS *is indeed* under the GPL. This means that all the fun GPL stuff applies to it. If you want to distribute binaries including GNU GhostScript, *then* you need to talk to them about a license.

    Just thought I'd clear that up, as most people seemed to have it confused...
  • No, it doesn't violate the DFSG.

    With the exception of the GNU GhostScript code (which is owned by Aladdin) we wholly own the CUPS code. We can distribute CUPS under any license we choose.

    The DFSG applies to a software distribution and a single license, not to all distributions and licenses that a package may have. Another example is GhostScript, for which there is a non-DFSG version (Aladdin GhostScript 5.50) and DFSG versions (GNU GhostScript up to 5.10).
  • This does not fail the DFSG in any way. There is a GPLed version; it trivially is DFSG-compatible. It is also possible to purchase, from the authors, a special dispensation to modify the code for use in a proprietary program. Note that the authors can give out the code under as many different licenses as they feel like.
    I'm not sure how they'll deal with third-party modifications to the code, though.

  • I'll make sure we add some info on how to use the CUPS trademarks. Basically we just want to protect the name so it doesn't get associated with something sinister... ;)

    For the record, and as far as our legal understanding goes, any person, company, etc. can use a trademarked name so long as they are identifying the product that is trademarked and provide the appropriate notice stating who owns the trademark. E.g.:

    GnomoPrint CUPS(tm) 2000
    Copyright 1999 by Gnomo Software, Inc.


    CUPS is the trademark property of Easy Software Products.
  • by Guy Harris ( 3803 ) <> on Friday October 01, 1999 @05:44PM (#1644040)
    The second is that a common printing system for UNIX does exist--but not for Linux. It's called XPRINT,

    Define "printing system". Section 1.1 of the X Print Service Extension Library documentation says

    Several keywords and concepts used in this specification were borrowed from the abstract standard ISO 10175, the subsetted standard and implementation represented by POSIX 1387.4, and the yet further subsetted implementation represented by OSF Palladium. The X Print Service does not attempt to duplicate the functionality or APIs provided by any of these print subsystems, or by any other print subsystems such as System V lp or BSD lp. It does, however, attempt to allow implementations to work with these print subsystem, and its architecture is open enough to allow tighter binding to a specific print subsystem in the future.

    CUPS is a "print subsystem such as System V lp or BSD lp[sic]"; XPRINT generates stuff to feed to a printer, and a print subsystem such as the SV or BSD one, or CUPS, queues up that stuff when handed it, and feeds it to a printer.

    So XPRINT isn't enough to do printing; you need a print spooling system, as well as a system for actually generating a file containing instructions to a printer telling it what marks to put on a sheet of paper (or what stuff to send over a fax modem, or whatever). CUPS is, among other things, a print spooling system; an X Print Server will probably assume that a print spooling system exists and that it should hand print jobs to that system.

    You could debate whose job it should be to turn printer-independent drawing instructions into the appropriate drawing instructions for a particular printer; if somebody wants to argue that XPRINT should do that, they'll have to demonstrate that it's OK to require all programs that print more than just plain text to be linked with Xlib and company, and to be run in an environment that has X Print Servers handy (be prepared to have to respond to people who do not want to be required to do that, and may even have good reasons not to want that).

    Oh, and I don't consider it a "UNIX standard" until I can rely on it being on all UNIX systems, even if I'm, say, in an environment where all the UNIX systems are headless servers.

    before anyone flames me, read the docs for XPRINT,

    I did (which I was able to do, because I happen to have Frame Maker; has anybody converted the various X specs written in Frame into a format that those who don't have Frame can read, and made them publicly available?), and they specifically indicate that XPRINT isn't a print spooling system.

    Someone PLEASE write an XPRINT module for XFree.

    What's missing? The XFree86 3.3.5 release notes [] say

    XFree86 releases starting with the 3.2A beta are based on the X Consortium's X11R6.3 (the final release from the X Consortium).

    R6.3 is an update to R6.1, and is intended to be compatible with R6.1 and R6 at the source and protocol levels. Binaries should be upward-compatible. X11R6.3 includes some new Xserver extensions: SECURITY, XC-APPGROUP, XpExtension (print extension), ...

  • by Yebyen ( 59663 ) on Friday October 01, 1999 @05:46PM (#1644041) Homepage
    BTW, I've already gotten an e-mail looking for the drivers i'm talking about, there are postscript drivers at []. Have fun! Moderator, please moderate this up as informative. I wanna be a moderator!!!

    Patrick Barrett

  • Actually, in Win9x drivers aren't required on all the client machines (at least for parallel port printers, i dunno about network printers). I have a two-computer network, with a Canon BJC-4000 on one of the computers. That computer has the Canon drivers installed, and the other computer can send stuff to print on it, even though there are no print drivers installed on that computer.
  • It's so late that much or all of this might be garbage, but I thought Xerox invented ethernet (physical layer) and Metcalfe invented TCP/IP (transport layer). The early Xerox networks ran XNS (Xerox Network Service?)
  • This would work great, except that I don't think the X graphical model is flexible enough to be useful for general document printing.

    For example, font handling. Win32 and MacOS provide a lot of detail about fonts that is necessary for good quality text layout and printing. X does not.

    Text layout, for example, is done on the display as well; are X's facilities sufficient for display but not for printing, or does X need to be improved (or replaced...) for display as well?

  • Yep, it's useless. Well, not completely useless. As a print queuing system, it's ok. You don't have any drivers unless you purchase them, and you may not get good drivers even then. (For instance, the HP672C driver is only marginally better thaan GS.) Assuming you have good drivers, and applications which begin to support it, you will eventually get the capability to control printer features like paper tray, output quality, paper type, etc. This is a good thing.

    However, it doesn't do anything for providing apps with printer support like Windows, Mac, Amiga, OS/2 and basically every non-Unix OS do. It doesn't help apps determine what fonts are ok, it doesn't help them create the output, it doesn't give them a working font model, font metrics, the kind of info in afm files, etc.
  • feeBSD? ;-)
    Man is most nearly himself when he achieves the seriousness of a child at play.
  • I believe he invented ethernet while working at Xerox. Then went on to found 3com.


    (Or, rather, he and Dave Boggs invented it; I have the impression Metcalfe isn't the sole inventor.)

  • Even the GPL allows you to contact the author and attempt to make an alternate licensing arrangement (the author can, of course, refuse). The DSFG, last I checked, allows for this. So CUPS doesn't fail DSFG after all.
  • There are similarities in the filtering mechanism, just as SGI's Impressario product and several others do.

    The main difference is that the driver-application interface is richer (you can actually find out what the printer supports) and you can add different backend interfaces (i.e. a new network protocol, serial ports, etc.), other drivers, etc. without a lot of work.

    Also, since IPP is the remote printing interface and CUPS maintains the available printers on the network, you don't have to administer the client machines, and the clients can actually send options to the servers.
  • Vint Cerf was behind TCP/IP.

    RFC 791, "INTERNET PROTOCOL, DARPA INTERNET PROGRAM, PROTOCOL SPECIFICATION", says that it was "prepared for Defense Advanced Research Projects Agency Information Processing Techniques Office, 1400 Wilson Boulevard, Arlington, Virginia 22209, by Information Sciences Institute, University of Southern California, 4676 Admiralty Way, Marina del Rey, California 90291", and RFC 793 "TRANSMISSION CONTROL PROTOCOL, DARPA INTERNET PROGRAM, PROTOCOL SPECIFICATION" says the same thing.

    I have the impression Cerf wasn't the sole author; I think Jon Postel, for one, was involved, and RFC 793 says

    TCP is based on concepts first described by Cerf and Kahn in [Cerf, V., and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communications, Vol. COM-22, No. 5, pp 637-648, May 1974]"

    so presumably Robert(?) Kahn was involved as well.

    In any case, as you note, Bob Metcalfe didn't invent TCP/IP.

  • The main difference between the magic filter stuff and CUPS is that CUPS supports things like *job options*, and the magic filters are still only 1 level "deep". CUPS can run multiple filters to get from file type A to B.

    ... as can magicfilter; in fact, this is one of the points of magicfilter. Claiming it's only "one level deep" is certainly incorrect.

  • Noooo, you just can't call your product "CUPS". You *can* call it "Gnomo CUPS", etc.

    Trademarks protect names from getting "diluted". You can use the name all you like, so long as you are referencing *the* CUPS distribution. If you have a derivative then you just have to modify the name accordingly.

    Please, think about Linux - it is trademarked but used regularly at part of the name of many Linux distributions.
  • by extrasolar ( 28341 ) on Friday October 01, 1999 @06:41PM (#1644076) Homepage Journal
    Geese you people. Certianly the traditional Unix printing system works great for people like us who only occasionally print technical manuals or perhaps source code. I know I have printed a LaTeX document or two for school. But have you ever tried printing a screenshot? Don't. I did once and the results were terrible.

    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.


Houston, Tranquillity Base here. The Eagle has landed. -- Neil Armstrong