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. "
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.
tcboo
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)
They clearly state that ANY patches/modifications and what not CANNOT be released under the name Cups. I find that as a problem that prevents effective redistribution of this product and makes it non-free. If Linus one day up and said, "Yes, you can make kernel patches, but you can't call that kernel a linux kernel when you make those patches," do you think that Linux would survive? That's what's going on here. They are saying "Sure, you can modify our program.. but you can't call it cups or anything to do with cups when you do.. so you better be prepared to modify ALL the documentation and what not to NOT say Cups.." I see your point, but what happens if "company A" decides that their NDA'd printer driver needs to go with the source of this program? What happens if they say , "We write the driver, and you distribute it with the GPL'd version." Now you see what I'm getting at. The DFSG does NOT stipulate for a Free vs. Non-Free version. The DFSG SIMPLY targets the entire program's standing. Since there is a non-free aspect of the program, the entire program is non-free. THat's what happened with QT , and why to this DAY KDE is still considered non-free.
Jarrod
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
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.
There is no room for this racist crap here .... sicko
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 am hoping this will allow me to dump NT for print (it's no longer allowed to do file). We'll see. The problem lies with HP and their funky lpr implementation, but before you make yourself look dorky (like I did) don't promote Linux for print services on net devices that will unexpectedly quit.
Go look at any of the FSF's projects. You can't get code in GCC without turning the rights over to the FSF
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.
___
If you think big enough, you'll never have to do it.
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!
how to invest, a novice's guide
Well, I just managed to answer my own question by reading the FAQs on www.cups.org. 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 cups-info@cups.org. 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.
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.
Business. Numbers. Money. People. Computer World.
Wow. I'm astonished that anyone could be so ignorant as to post something like this on Slashdot of all places. I wonder if this Anonymous Coward realizes that psychologists have recently determined that extreme racism is actually a chemical imbalance, and not just complete idiocy. And seriously, what has affirmative action done to hold back the open source movement? I didn't realize they had Affirmative Action in Finland. Like the other commentor said--There's no room for this racist crap on Slashdot. Free your software, and your mind.
7.Distribution of License The rights attached to the program must apply to all to whom the program is redistributed without the need for execution of an additional license by those parties. That is cluase SEVEN of the DFSG. NOte it does NOT say that the "VERSION" of the program has to apply to all, it says the RIGHTS attached to the program must apply to ALL TO WHOM THE PROGRAM IS REDISTRIBUTED. Since there exists a binary edition, the rights DO NOT EXTEND to all. ERgo.. non-free.
The place where I used to work had someone running around, installing printer drivers on all the windoze clients every time a new printer was added to the network. Very stupid, but we thought it was required. Why does Netware 5 Zen Kind-of-works come with a printer driver distributer then? (Another guy at work, known as Captain Braindead, was supposed to set that thing up...but never did)
Sticks!!! You had sticks?!?!?! We had to scratch the dirt with our finger nails.
-matt
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!
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.
Business. Numbers. Money. People. Computer World.
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
Auditing and dentistry are excellent career choices for people who don't like other people but aren't coordinated enough
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?
Business. Numbers. Money. People. Computer World.
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.
"you look like the gay version of a homo in a fag costume" - Greg_L
I can only say..
IT'S ABOUT TIME!!!
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
MoNsTeR
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.
-Chris
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.
Will in Seattle
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 Norton Anthology of English Literature, 4th Ed., Vol 2
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.
I'm boycotting printers! FOREVER!!!
See, I've never used them before...so one long programming night I decide that it would be nice to download the ROM (Rivers of Mud) source code and print out the socket code for reference (ever notice there aint too many *NIX socket references?)
So everything is going along just fine, right? Well, I tried to print 1.5 pages, and somehow I f*cked up and printer all of it. Yes, all of the ROM code, all those thousands of pages. My boss wasn't too happy with me =)
Printers are the Devil incarnate!!!! BOYCOTT PRINTERS!!!
Heh.
Shh! Nobody knows I'm gay!
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).
At my last work I went to add the printer from the printer server. It asked me for the WinNT CD so it could install the drivers. Too lazy to get up from my desk to get the CD, I just connected to a coworker's workstation's share of the same printer. No drivers installed, it just worked.
They clearly state that ANY code written and submitted /used by them was their property. So does the GPL extend the right to take code?
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!
My Freakin Blog
"I would MUCH rather have proprietary and/or "quirky" drivers to the complete lack of drivers that are out there now. "
I take it you've never had to fight against a "quirky" driver. And the fact it's "proprietary"(read binary) simply means your job's that much harder. Still want to give in?
.. are secondary to the fact that EVEN IF YOU wrote modifications and what not, you CANNOT REDISTRIBUTE it under the name Cups because they've asserted the trademark to it. So.. you can make all the fixes you want, and can't redistribute it under the Cups name. Jarrod
i bet you could make a kickass beowulf of printers using this CUPS thing..
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
The QPL was NOT dfsg compliant, as the QT is NOT The software. The software created using QT was NOT DFSG compliant, which is why you'll still be hard pressed to find QT software in debian. The reason is because the redistribution is 'illegal' in Debian's policy mindset. Now with Cups, the software product is named = "Cups", is it not? But any modifications you make to it cannot be named "Cups." The drivers you make for it cannot be named "cups-drivers" The program is not released under one license, it's released under TWO. While the GPL does not blanket over an entire program, the DFSG DOES, and therefore would also have to cover the binary only edition, in all it's glory. The binary only edition may include non-free non-open sourced drivers. Ergo, this means the product itself is NON-FREE with a Gpl'd version. The program is non-free, but there is a free version of it. Big deal. The DFSG is worded that the program must be ENTIRELY free, not partially free. If Debian adopts this (which I doubt, there are no printer drivers for it.. they may fork it on the other paw..) then it will not be put into main unless they blatantly fork it and call it the "Debian Printing System." Under the name "Cups", this product is non-free.
Jarrod
I've been using PPR (http://mouse.trincoll.edu/ppr/docs/index.html) 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.
Absolutely not. See their FAQ on this at http://www.cups.org/faq0006.html. 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 www.cups.org/bazaar.cgi, 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. :)
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 a historical, semi-ironical note, wasn't it a proprietary printer driver that sent RMS on the GNU trip in the early 80's? :-)
---
I've done this before myself. It works great on a small installation with one printer, less well when you have many printers with different characteristics (your end-user software has to understand all of them; if you add a new one, you have to reconfigure the "print" script on every client machine).
Of course, the real problem is that there are M different formats people want to output to the printer (in some sense, many GUI applications have their own internal format which you can include in the M) and N different printers you want to render those formats to.
The traditional Unix answer has been to declare PostScript the intermediate language: turn all M into PS, then figure out how to render PS on all N. It makes sense to put the first step as close to the user as possible (since it's the user that cares about what kind of data they're printing) and the second as close to the printer as possible (to make it easy to add new printers).
(Is PS the right intermediate? *shrug*)
This is, of course, what almost no currently operating system does -- they mostly put _all_ the logic on the server side (a la CUPS or magicfilter) or all the logic on the client side (your solution, or the default Unix behavior of just giving raw access to the printer via 'lpr'). From what I hear, the X printing stuff might be a step in that direction... CUPS is not, AFAICT.
Very true. I can see forking the code.. but I still and will always see the Trademarking of the name CUPS as banning redistribution of "Cups" and therefore it fails DFSG. That's just the way I see it, and I think that also kinda pulls it away from the intent of the GPL. My opinions, though.. I've got lpr working fine here, no need to change what works :) Jarrod
The basic ideas is simple: You have a script (call it "print" or even "lpr") which does local (even per-user) spooling while it does all the file reformatting (using aps2ps, Ghostscript, pagers, etc.) and then sends the "cooked" print job off to the standard lpr system (local or remote). Each physical device has one and only one lpr spool instead of the insane method of haveing different spools for different types of print jobs. The print script can take all kinds of custom options and/or work off config files. The think could quite easily be wrapped with a GUI system that would avoid the need for command line option expertise. Make the pre-spooler smart enough to process short jobs before very long ones, limit the number of jobs simultaneously being processed, other neat stuff like that. I guess you could get the processing to be done remotely too. One neat feature is that my /etc/printcap file is almost empty and I have no print filters to mess with in the spool directories.
That's what the XPRINT extension supports; it then hands the resulting output to whatever print spooler system you have.
Windows uses the same API for screen and printer output. GDI functions take a parameter (called a device context) identifying the required output target. This can be the device context of a window on the screen or a system printer. Apart from taking care of pagination, and an extra step to end the job on printers, screen drawing and printing are identical from the application programmers point of view.
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.
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:
To summarize, Windows printing system can be considered as similar for using PostScript or xlib from any application, with the provision that your PostScript processor (Ghostscript) or X11 can transparently use a printer or the screen.
--
Ihab Hussein
ihabhussein@yahoo.com
Time will tell. There's no way either of us are going to change the others mind, so we'll just have to see what debian thinks of it.
If you are using an NT 4 server and NT 4 workstation (or now w2k) the drivers reside on the server and are not downloaded to the workstation. For older (3.x) NT workstations, Windows 3.x or 9x, the server will hold the drivers and allow the clients to download them when the printer is created.
Damn - I guess that MCSE was worth something.....
Actually, magicfilter is more than one level "deep". The "fpipe" "pipe" "filter" and "ffilter" commands, by definition, send the results back into the filter script. I personally have text files going through enscript, to ghostscript, and with my old printer it then continues through pnm2ppa into the printer.
Maybe printer companies should stick this PCL garbage up thei... nevermind. Why dont companies make low-mid end printers with postscript. argh!. I have been looking for a 1200 dpi b+w laser with postscript forever, at a relatively ( $1000) low price. I may be dreaming, but postscript is way to rare. Seemed like a nice standard to me....
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"
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"
I looked for the three printers I use regularly (two inkjets and a laser) and they are not supported on the free or commercial side.
Ghostscript supports them.
Corel should have the driver for #3 out early next year.
Give me a break, another pseudo-free license, and it really doesn't give you a whole lot more (in my case less) than what's already there.
Boo.
By that metric, TeX is not free, and thus the GNU system is not free either. Finding people who chases RMS from the left is always surprising.
At least the same fscking people who wrote the god damn DFSG says so. Who are you to deny it?
Indeed, as usual. In 1985 I had a Xerox 1108 (Dandelion) workstation with megapixel display, nice three-button optical mouse, and, of course, ethernet. Original big, fat, thick-wire ethernet that you have to cut into with a special tapping tool to add a drop-lead for a workstation (and you could only cut taps at particular intervals which had something to do with the wavelength of the signal.
But this was Ethernet, not TCP/IP; I can't remember the name of the protocol they ran, but I do remember that when our ethernet was (later) connected to the Computing department's ethernet, all their VAXen crashed and they were not best pleased with us...
I'm old enough to remember when discussions on Slashdot were well informed.
Yes siree! The FSF requires you to sign ownership of your code to them before allowing it into official FSF packages. Now, your problem was...
It all boils down to this: It isn't your site. They can post whatever they want. If you don't like it, don't read it.
RedHat does that already!
(running multiple filters fo get from A to B)
I have tried printing a screenshot and it worked great. I think it depends on what you feed it to. I have a postscript laserprinter. And I get a lot better quality from it with linux then with windows. OK, the windows drivers are sucky, but still...
No, you have to listen to the Real Audio PBS solutions. It is much easier to hear someone describe the solution than to read the man pages.
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 and that should give you essentially the same functionality as you'd get from OS/2, Windows or MacOS.
Also kind of neat is the Universal Printer Description Format (UPDF) being worked on over at The Printer Working Group's web site. I've met with them and it seems like they are a clever bunch of people who do printing for a living trying to set aside corporate differences to come up with a standard that will benefit us all. They've mumbled stuff about CUPS to me and waved their hands vaguely but it seems to me that CUPS doesn't go nearly far enough toward fixing what's wrong with UNIX printing.
YMMV.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
And that core nerd trait would be... great wealth?
I am a self-taught sysadmin runningan HP-UX network of 60 or so nodes; our office machines are
M$ boxes connected thru samba. Are you suggesting that I buy "only the best" software & hardware for my company? I clean the printers, upgrade the hardware, train the users, write the inventory barcode perl scripts, maintain security, etc.
I'mnothalfas smart as half of you, but by Darwin, I'm doing real work and have real contraints. If it works, I use it. I don't have time for replacing "good enuf" with elegance. A sawmill has a limited budget for their MIS department.
- freehand
Wanna use OCL on any Unix ? http://www.unibol.com
Linux port coming soon! (Ok, were slow..sorry!)
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.
Can someone explain me what is the difference between this and Apsfilter (except that network printing and automatic doc. type detection)? I've been using Apsfilter about couple of years without any difficulties (formerly with HPDJ550 and now with Canon BJC-6000, which isn't even a supported printer).
;)
And what was that talk about selecting suitable filter e.g. to print PDF files? I thought that to convert all images, PFDs and text files to PostScript is easy enough.
Well, maybe I'm too old to understand this kind of new technology
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.
Trust the Computer. The Computer is your friend.
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)?
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.
And *thank you*! Magicfilter is a wonderful system. It's still being maintained by david parsons.
DIRT?!??! We had to scratch markings into primal ooze!@#
Yes, real PS. Check their site.
Pencil! Luck Bastard! We had to scratch in sand with a blunt stick!
Actually, I wasn't commenting on the protocol itself as much as the dripping marketting hype.
IPP development was/is backed largely by Novell and HP, among others. Gee, that's the first time something from HP has been been accused of "dripping marketing hype" since 100VG AnyLAN (yuck!). And it's the first time anything from Novell has been accused of having any hype, ever.
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.
Um, that would be a "WinPrinter," and we don't want no stinking WinPrinters in Linux!
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!
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 would think most of the community here would disagree with you. Nerds or geeks tend to demand technical excellence and won't put up with sub-standard products. That's probably one of the underlying reasons that we support Linux so much. Because we think we can do a technically better job than Microsoft writing an operating system -- and we seem to have done so, no?
I think it would be honest and accurate to say that we would gladly pay top dollar for the technically superior hardware device. Unless we had an absolute immediate need I don't think anyone prefers a cheaper product that has "proprietary and/or 'quirky' drivers."
I believe it was a Xerox printer driver.
Postscript, HP JetDirect IO cards, and lpr. It's worked every time, for me...postscript for 15+ years, lpr forever, and I've used the great HP cards for just a few years, but they have worked beautifully. Don't mess with success.
- real hackers don't have sigs -
The above poster (if nested) has it right. An NT print server will download the driver to a NTWS "transparently". That's why when one updates the print driver on the server, it automatically updates the clients whenever they use the printer in question. You can see this by watching the client screen closely or checking the event viewer.
_damnit_
_damnit_
It's my job to freeze you. -- Logan's Run
I hope that your fees arn't exactly cheap. I've never seen a printer company that couldn't spare a few thousand $$$. Since they could always just release the source, it seems fair. Also, if you charge enough you could donate some money from each licencee to places like the FSF or SPI..
The "Meta language" is the EMF Format (Enhanced Meta File), afaik, an extension of the WMF (Windows Meta File) Format, which also is more or less a record of GDI drawing operations.
RedHat, the distro which should probably be reccommended to all newbies, makes printer setup cake with its printtool. There are some limitations of printtool which don't allow you to set up some of the more interesting (and less useful) features of lpd, but it generally gets the job done, even for setting up a network printer (like the wonderful HP4000N).
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. --While it may not be as sophisticated as CUPS, you can indeed use multiple filters with lpd; you simply pipe them through one another in /etc/printcap.
Actually, some of them do use ghostscript.
They're called "postscript compatible" so that the unwashed masses don't get confused.
If J.K.R wrote Windows: Puteulanus fenestra mortalis!
How is this any different from the printfilters package Red Hat has been shipping for some time now?
www.eFax.com are spammers
This has been discussed elsewhere, but companies wishing to make proprietary printer drivers may buy a non-GPL license.
From a brief romp on their FTP site, I don't see any source archives. Maybe they'll come later? I'd hate to see a project like this not have its source code available under an open source license.
I would say we (well, GNU. ;) should make an open free standard similar to postscript, but alas we can not seem to affect the hardware industry.
> We're doing that for CUPS for the same reason that Linus trademarked Linux...
Um, Linus _didn't_ trademark Linux, some jerk in New England did, and it ended up being cheaper to pay him to transfer the trademark to Linus than to get the PTO to void it. Now, that in and of itself may be a good reason to trademark CUPS (although I doubt it - after all, it's not like I see a flock of people distorting the LPRng name), but at least get your facts straight.
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. Why should I run X on my print server? It takes up resources, adds security problems, and is less stable than Linux without X. Lpr works _great_ for me; I've got an HP4000N, and I'm printing from Linux, Windows, and Mac workstations. I've also got the duplexor options and auto-tray-selection-by-paper-size, which both work great. I really don't see the need to try anything else, especially a printing system which requires a seemingly un-printing-related program (X).
Not checking for NULL is very poor software engineering. A check for null is a single operation running in theta(1).
for Ibegin
for J
begin
if a[i] 0 then
begin
a[i] = a[i] + 1;
end
a[i] = a[i] * 2;
end
end
Analysing this algorithm, we see that it still runs in theta(n^2) time (n^2
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.
X needs to be improved.
As an example, the WINE project has great difficulties with X's poor font handling. It doesn't provide anywhere near the capabilities of the Win32 interface, and thus makes it very difficult to emulate those parts on Win32.
I have wondered if Display postscript could be the answer to X's font woes, but I don't know enough about what it provides, and in any case, the GNU version isn't at production level yet.
Not checking for NULL is very poor software engineering. A check for null is a single operation running in theta(1).
for Ibegin
for J
begin
if a[i] 0 then
begin
a[i] = a[i] + 1;
end
a[i] = a[i] * 2;
end
end
Analysing this algorithm, we see that it still runs in theta(n^2) time.
for nerds, or being stuff that matters?
Is it because it is 'GPL'?
Is it because it says 'Linux'?
Its *NOT* the 1st alternative to the stock LPR. And the one review of the code commented on the buggy nature.
When will the by-line become "news for GPL, stuff that is GNU/Linux"???
So, why does this story rate?
(And where can you send comments to the 'staff', rather than having to post to a thread to ask 'how is this news for nerds'
The sooner X is replaced, the better. And don't whine about "you can write extensions to..."
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
I saw this on Freshmeat and found it very interesting.
As a pseudo-newbie I'd really appreciate it if somebody who installs this on a Red Hat system provides a report... How to do it, how difficult it is, how useful it is, etc...
I assume SOMEBODY's going to rush right out and set this up...
/* The beatings will continue until morale improves. */
L.
there are 3 kinds of people:
* those who can count
there are 3 kinds of people:
* those who can count
* those who can't
All the drivers are (can be) on the Server, it's been that way since Windows 3.1!
You need to keep your knowledge up to date, before you present it as fact. It only makes Linux Supporters look bad, F.U.D. indeed!
Indeed, as usual. In 1985 I had a Xerox 1108 (Dandelion) workstation with megapixel display, nice three-button optical mouse, and, of course, ethernet. Original big, fat, thick-wire ethernet that you have to cut into with a special tapping tool to add a drop-lead for a workstation (and you could only cut taps at particular intervals which had something to do with the wavelength of the signal.
:-)
And they called the tapping tool a "Vampire Tap"
Most vendors have gotten smart and now release an "alternate" driver for 9x and 3.1 that's just OEMSETUP.INF, for NT client installations. Even HP does this now.
-witz
I'm quite a bit newer at this, but lpr works just fine with a HP4000N. Printing from Windows, Mac, Linux clients. Actually, I am not necessarily using Postscript, the Win clients are using PCL. However, it doesn't matter as the printer auto-selects PS/PCL depending on what is thrown at it. No need for a print filter, it _is_ a print filter. Love it.
Glad to hear Adobe (which contribs to my son's school in Fremont (Seattle)) is moving towards Linux. I think the main reason their tools are beasts is that you have to live with the Win/NT OS. If they could just jettison that, I could move my whole setup off Windoze - since Borland is going Linux too.
... maybe they'd get the hint ...
Maybe I could drape Waiting For The Interurban (across from their offices) with Penguin t-shirts and masks
Will in Seattle
Oops- you probably saw that in the old "overview" document; it should be updated now...
I print, therefore I am.
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!
Well this looks like another step in the unification of Unix versions. Assuming that companies like IBM with there AIX adopt cups at some point, as well SUN and there Solaris. It will be interesting to see how many *NIX flavors adopt cups in the next 6 months. It will also be interesting to see how many printer manufactures use this system to make printer drivers for *NIX flavors.
Only 'flamers' flame!
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.
Red Hat did exactly what you claim Debian did (I don't actually know what Debian did) -- they allow use of Red Hat in the name (e. g. "derived from Red Hat Linux" or whatnot), as long as it's clear that it's not the official package. I don't have the URL to the letter that they sent out about it, but it got heavily publicized on Slashdot and Linux Today, among others.
Red Hat acted honorably here. They want to use the trademark to make it clear to customers what they're getting, not to screw anybody (except people who wanted to pretend that they were selling the official package with support, as opposed to a cloned CD).
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.
Cheers
-jwb
The printer$ share on a win9x box is actually the %windir%\system directory. Which of course contains the registry.
Just thought that was interesting.
Hands in my pocket
> 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.
I've finally had it: until slashdot gets article moderation, I am not coming back.
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
When I think of free software I think free speech not free beer.
When I think of Easy software should I think of easy women or easy money?
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?)
Yup, as I said.
RMS != Debian. Debian still calls it non-free or illegal.
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.
I am not a lawyer, but I am a law student, and I am taking a class on Trademarks. Basically
what you have said is correct. Any fair use of the trademark is allowed. The courts have interpreted fair use to mean the use does not seem to take away from the trademark owner what is rightfully his.
In other words, what Printman has said. If the company using CUPS attributes the mark to EasySW than it's all good. Trademark's are designed to allow companies to leverage their reputation.
One question for printman, It seems to me that the CUPS is not registered with the PTO, are you guys seeking registration? Have you consulted with lawyers? This isn't a flame, I was just wondering. Based on what I have learned in school, and over the summer doing trademark work for a law firm, it seems like there might be some problems establishing CUPS as a trademark.
Why don't I just download the code, change it, and not tell anybody?
My Freakin Blog
Common printers like the HP Laserjets are not supported. CUPS is a good idea, but without drivers it is essentially useless...
Must not be using NDPS?
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."
We haven't had a chance to finish the incoming LPD interface; it will be a separate thing from the scheduler and *won't* work if you've turned printer authentication on (that is, requiring a username and password.) It'll probably show up on the 'bazaar and then become integrated once we start the 1.1 betas (not anytime soon ;)
The main goal of 1.0 was to implement a new printing system that would work on all UNIX's. We originally were going to base it on LPD but extend the hell out of it.
Shortly after we finalized a preliminary design we discovered IPP. The switch to use IPP caused a complete redesign and required development of the network stuff in a completely different direction, so all of the LPD client stuff went out the door, at least for 1.0.
I print, therefore I am.
...*NIX printing will catch up to Windows 3.1. Two years of working for free in my spare time for the glory of writing obsolete printer services+drivers? Thanks I've got better things to do.
What if vital parts of the drivers are licensed non-GPL?, you have to have a middle-ground between Closed and Open, just consider this a fenestration :)
..and you can telnet to them om port 9000 and screw them up completely. :)
If J.K.R wrote Windows: Puteulanus fenestra mortalis!
It's seems a little useless to have a free printing subsystem, but the collection of drivers is $300-$500. Granted Laserjet and Deskjet is a big part of the market, but... Does this mean that this thing needs to be drydocked until the community rewrites enough printer drivers to be truly universal? Also, is this truly that big an advance? Does it bring printing under Unix up the standards of NT/Windows (or for that matter, the Mac)?
No different than Display Postscript on the Nextstep platform. ftp://developer.redhat.com/pub/rhcn/RPMS/i586/dgs- 0.5.0-2.i586.rpm Will give you something similar.
I've been doing chaining with some success using lpr...i'd like seamless chaining i.e. print_job_on_some_system (mac/pc/unix) -> (server) -> (print server) -> (printer) and proper remote admin (preferably without logging in) with secure authentication...something lpr currently doesnt have.
On NT, the drivers live on the print server. They are never downloaded to the client workstation. Print jobs are handed to the print spooler on the server 'as-is', using whatever internal format Windows uses for print jobs in progress. (this is documented but I am too lazy to look it up :) )
You are confused with 95, which downloads print drivers from an NT server IF the NT server is set up properly. 95 requires print drivers to be local. NT clients do not.
I don't know what 98 does. I've never tried to print with it on our network.
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
I don't know why we should complain about this, /.'s source code is effectively unavailable and won't be for a while. That is pretty hypocritical for the champion of open source I think.
--> Fight tyranny and repression.... read
Yah I see it.
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 cups.org
----------------- "I have a bone to pick, and a few to break." - Refused -------------------
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.
Derek
Where are my moderator rights when I need them?!
Source code for what, scripts?
Err, I just downloaded Slashdot's source. Haven't put up a site quite yet but I will soon. It's not GPL, more of a BSDish licence but who cares as long as you have the source.
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.
try browsing their site... they only give you deskjet and laser jet drivers. If you want other ones, it looks like you have to buy their commercial product based on the system. It only costs a few hundred dollars for the free CUPS core plus the drivers they should provide with their GPL software. Doesn't sound like such a hot deal to me.
Sometimes the naivete on \. blows me away...
Of course, the big question is why a printer driver must needs be a trade secret.
Do you have any idea how much money Adobe has made on Postscript drivers and engines? The answer is lots and lots. You see, there are these strange people out there who actually believe in capitalism.
didn't you ever wonder why NT prompts you for drivers for win95, nt.3.51, etc, etc? it's because the client will download the proper driver from the server.
Actually, Aladdin has been nice enough for some time to rerelease an versions of over a year in age under GPL. So, you can grab Aladdin's current GS under their license, or the GPL'd version.
Win NT Server keeps the printer driver files on the server - when a client adds a network printer it installs them on the client as well.
You can designate in Samba where to keep these printer files so that when windows clients add the network printer the drivers get installed.
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.
While you're waiting for Adobe, check out PDFlib:
http://www.pdflib.com/
It's a PDF file generator that works on Windows and UNIX. You can use it as a CGI. It's not open-source, but it comes with source. It's one of them free-for-individuals, costs money for businesses deals.
Our company does 360 feedback (performance appraisal by bosses, peers, and subordinates), and we use PDFlib to generate a report right on the web!
Patrick Barrett
Yebyen@adelphia.net
Restating the obvious since nineteen aught five.
Vint Cerf was behind TCP/IP.
Scuttlemonkey is a troll
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
For a couple of years now I have had very little trouble with my printer running under linux. First Slackware and now Redhat. It's a Cannon BJC-610 and is now supported under Ghostscript's UPP drivers (filter setup is finally made easy now with RH printfilters.)
/etc/printcap and print to that.
Samba even lets my Win98 box print to it with Cannon's windows drivers. If I want different resolutions for printing in Linux I can just add another entry into
I just don't see what's so great about this CUPS - I thought that there were already a couple of common print spooling systems....
Could it be that this company is just trying to make money by selling the drivers for this?
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..
When I tried ESP Print Pro about a week ago, I found that printing took at least twice as long as GS. The output on my HP672C was better than GS, but it was nowhere near as good as the windows driver. Certainly not worth the cost of licensing it, which would be over $200 so I could let 3 machines print to it. (As far as I could tell, the demo shipped with a network-disabled version of CUPS, and it looked contrary to the licensing agreement to fix cups with the single-user/personal edition so that my home net would print.)
Sorry, thanks but no thanks. I'd rather purchase a PS color laser for $1200.
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...
æeee!
Gotta agree with the cowards here. I just set up network printers on a LAN, and watched the clients suck down drivers from the server and install 'em.
Windows DOES have have a device-independent language that gets passed to the drivers--I think it's GDI--, but it looks like no one was bright enough to send GDI over the network before converting it for a specific printer. Or maybe it was impractical to use GDI. . .
If I am, in fact, wrong, could you explain how to set this up? I guess you could fake it if you had PS files and a PS printer, but otherwise. . .
> Geesh...I remember when I had to write my own network spooler
Well, I remember when printing was done with a pen, or pencil, or maybe a mimiograph (I have forgotten how to spell it)
My Epson Stylus Color 600 is supported very well by Ghostscript. The major annoyance, much like not being able to change bitdepth on X on the fly, is not being able to change the resolution of the printer on the fly (or maybe I just don't know how to do this). Sometimes I want something printed nicely, sometimes draft, and I don't feel like having 2 printer devices to do this. Will CUPS allow this?
I like the concept, but it violates the DFSG by offering to sell a binary license while giving the GPL the sidestep. THat discriminates against fields of endeavorr. GPL clearly states that the modifications CANNOT BE CLOSED, ergo, this company has no rights to sell a license that allows modifications to be closed. Sigh. No, I won't be using this scam. Jarrod
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.
Daniel
Hurry up and jump on the individualist bandwagon!
Xerox created ethernet, eh? I thought that was everyones friend, and 3com founder Bob Metcalfe, the Linux basher^H^H^H^H^H^Hlover!
=)
Sounds the same to me.
feeBSD? ;-)
--
Man is most nearly himself when he achieves the seriousness of a child at play.
****Gfx Scrollbar Special case hit!!*****
I've been hacking on a driver for the Epson Stylus Photo EX for a while. This is actually Michael Sweet's driver for the Gimp print plugin, ironically enough.
:-) ) could tune the output for different papers.
It turns out that Epson has (at least) two levels of their developer documentation, beyond the standard documentation for their printer language (ESCP/2). The "Level 1" documentation on their developer web site (http://www.ercipd.com/isv/edr_docs.htm) gives fairly detailed documentation on the printer, but there's at least one mroe level of documentation that's available only under NDA, which (obviously) I don't have. So I've been able to get very good print quality, but not the level of quality the printer is ultimately capable of. I've found another Ghostscript driver around that apparently does know how to achieve the higher print quality (looking carefully at the printer output it's obvious -- with an 8x loupe and simply looking at the micro-banding, it's clearly doing something different), but I haven't had time to study the code yet (my driver seems to produce better fidelity).
BTW, if anyone would like to hack on my modifications to Michael's Gimp plugin, it's available at http://www.tiac.net/users/rlk/print.tar.gz. I'd like to find more people to test this and make suggestions; it's become a rather expensive hack (in terms of paper, and particularly ink).
Whatever my thoughts about the multiple levels of documentation, though, I don't particularly blame Epson for putting the smarts in a software driver. Dithering algorithms and such for 6 colors (CMYK + light C + light M) seem to become very complex very quickly, and having this stuff be under software control makes it much easier to experiment with changes. For example, my driver achieves higher color fidelity (visually compared to my monitor) than the driver Epson bundles. It actually makes the printer a MORE open device than if the firmware were embedded. I wish Epson would put the entire programming information on its web site, not just parts of it, but at least I (or others who know more about color and dithering than I do) have a chance of reverse engineering the format and improving the output quality beyond what even Epson achieves. A true PostScript printer certainly has a very open interface, but a closed implementation. As much CPU as this consumes, I think that for printers such as this, having an open implementation is very valuable.
Examples of improvements that could be made:
1) More user-level controls (I've added gamma, contrast, and color level controls to the existing set). This enables fine tuning for a particular image or monitor.
2) Different kinds of paper. Images print very differently on different papers. Photo-quality glossy paper is different from "photo-quality" coated paper, which in turn is much, much different from standard ink-jet paper. This is mostly due to how much ink the paper absorbs. People who actually know what they're doing here (as opposed to dabblers such as myself who like to shoot off our mouths
3) Different inks. I bought a third party cartridge because it was the only one I could find at CompUSA. Its color balance was somewhat different. Conceivably a third party might devise archival inks (that don't fade rapidly) that have different colors and densities. With a software driver the printer really does become open; if it's in ROM on the printer, there's no adjustment for it.
4) Improved dithering algorithms. Someone might devise better dither patterns to get smoother output.
[bobh@upland bobh]$ cat printfilter
/usr/local/etc/bj10e-filter
#!/bin/bash
cat - |
Now I add "printfilter" to /etc/printcap rather than the magicfilter (bj10e-filter) directly. Works fine on my Caldera 2.3 setup. I've been using Magicfilter for years and it has worked great.
$ cat printfilter
/usr/local/etc/bj10e-filter
#!/bin/bash
cat - |
Now I add "printfilter" to /etc/printcap rather than the magicfilter (bj10e-filter) directly. Works fine on my Caldera 2.3 setup. I've been using Magicfilter for years and it has worked great.
ESP owns the CUPS trademark (although there is a Java parser generator called CUP), so any fork couldn't really use the name. Hence, JAC Ain't CUPS (JAC) is born.
This is similar to Ghostscript's situation. Peter releases old versions under the GPL, but sells commercial licenses for the latest version. He's somewhat vulnerable to forking, too.
MySQL has started doing the same thing. It won't be long before someone ports the GPL version of MySQL to Windows. MySQL is almost freely available under Unix, but not for Windows.
You can use the trademark I know, but can you say your product includes the trademarked name? Like Joe Schmoe's gas station can't say it uses Techron (tm) fuel, can it? They own the rights to commercial use of the name, or something to that effect.
From their FAQ page [http://www.cups.org/faq0006.html], I quote "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.)" That doesn't seem right ... you have to give all the rights to YOUR code to them or let them sell it for their gain in binary only form or you don't get to contribute. That doesn't sound in the spirit of a true free software project. I wonder if this will die quickly or we will see a code fork.
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.
Linus Torvalds has the trademark on Linux. RedHat has the trademark on RedHat. Neither the GPL nor the DFSG says anything about your ability to modify code and claim it's the original version. That is what trademark law was made to prevent. Just as I can't can't write an operating system and call it Linux, you cannot write a printing system and call it CUPS. However since CUPS was released under the GPL, it (the real version) may be freely redistributed as specified in the DFSG.
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.
It is very common for a product to be licensed under more than one license. One example would be GhostScript. Effectively, a product which is dual-licensed can be considered two products, the Free one and the non-Free one. If someone releases a driver based on the non-Free one, that in no way compromises the integrity of the free one. What has been done with CUPS is actually alot better many products, as the version of CUPS which isn't Free is exactly the same as the free version.
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
CUPS was released under the GPL, therefore it must stay under the GPL. This is consistant with the DFSG guidelines. If companies want to redistribute it under a different license, they may, however once again, they may only do this with the non-Free version. The version which was released under the GPL must be redistributed under the GPL.
CUPS is certainly compliant with the DFSG, as by definition, any GPL'd program is.
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.
--