This makes more sense than it might first appear. By adding this to CUPS, you can take advantage of its print spooler, filter pipeline, and OS connectivity support (USB, parallel, etc.).
Thanks. This seems it was prepared before the February BOF and is out of date. Even so, it is a pretty solid read for someone interested in an overview of current 3D printing models. Unfortunately, it also makes it clear that the white paper currently only supports FDM (fused deposition modeling) based processes, while stating intent to expand to broader scope.
No, it makes no sense. Right now 3D printers eat files, so printing to file is tautology. 3D printers also tent to be very unreliable, you need ability to pause the print (jams, skips). How is putting CUPS between you and the printer helpful?
> Right now 3D printers eat files, so printing to file is tautology.
"Print to file" is a widely-supported printing operation, where the spooler saves the prepared document (in whatever format the printer uses: PostScript, Diablo 630, XPS, PDF, something proprietary...) to a file, rather than sending it down USB/parallel/etc.
> 3D printers also tent to be very unreliable
Plenty of regular printers are too, particularly older ones. Printing systems can handle it.
> you need ability to pause the print (jams, skips).
This is also needed, and supported, for regular printers.
> How is putting CUPS between you and the printer helpful?
Well, otherwise, you need some other software. Unless you're proposing people do `cat file > /dev/usb001`?
In addition to the other replies, there is also the ability to unify slicing from common formats into the data necessary for each individual printer.
I'm not up to date on the current state of the art, but 15 years ago industrial 3D printers required solid model generation, slicing using either some proprietary software or solidworks, and transmission to the device over network share, ftp, or sneakernet. Some or all of those parts could be common to a print system, reducing the scope for machine vendors, and allowing operators to mix and match components in interesting ways.
> 3D printers required solid model generation, slicing using either some proprietary software or solidworks, and transmission to the device over network share, ftp, or sneakernet.
These days(for me, and most of the stuff I've seen) it's solid model generation, slicing using free/open source(slic3r or equivalent), transmission over usb.
It's an interesting idea, but part of the problem is slicing is currently a tricky operation. I change settings based on a variety of things. I'm not certain what this is cutting out, cause I doubt they made their own slicer. If this is just taking pre-sliced data files, then you have to run everything through your slicer before you can send it to CUPS anyways. If they are integrating a slicer into CUPS, that'd be interesting, but I'd be really interested to see how they handle the many many settings that you can(need) to configure to get your slicer to output a file that the printer will work with.
Another issue is quality of progress display. I like to be able to see the print while it's printing, and track variables like temp of the printhead and progress through the print. Bear in mind, the average hobbyist 3d printer is going to take more then a couple hours to print anything of halfway decent size, so "oh you can just sit and watch it" isn't an answer. I personally use OctoPrint, which lets me track the print, and even see it using a webcam.
I stopped printing on Linux when it switched from the old printcap based tools (which while hard to configure, mostly worked) to CUPS. I was an experienced sysadmin, but no amount of configuration could make CUPS print anything but the text of postscript files to my laser printer.
I'm sure it's gotten much better, but CUPS is pretty opaque, and when you're doing 3D printing, controlling the conversion pipeline from model to print code is typically done manually with a great attention to detail.
I'm kind of surprised to hear that CUPS gives some people so much trouble. I've been using OS X and Linux since around 2001 and neither have given me any mentionable trouble with printing. It's always been install drivers -> flawless printing. In the case of my newest printer, I didn't even need to install drivers since it's AirPrint compliant. CUPS has been great for me.
This mirrors my experience. When I was in college I was always able to plug some random person's printer in via USB and it "just worked". I'm also able to autodiscover and print to all of the laser printers at work. (this is on Linux)
Have you tried debugging things when cups doesn't "just work"? printcap was much simpler, which made it easier to understand and diagnose problems.
In general I think there's a positive correlation between the precentage of cases where software "just works" with no manual intervention and the effort required to diagnose the cases where it doesn't.
Yes, I spent plenty of time debugging CUPS in the old days. But I haven't, in ages. printcap may have been simpler, but shortly before CUPS was released, the linux implementation had matured significantly and could do many basic conversion operations. Distros supported this and handled things like ghostscript conversion.
These days, I print in a number of ways that work fine, including Mac OS X (a version of CUPS which has already been debugged and polished for many printers I use), Windows (my preferred printing system since it supports the largest number of printers), and Google Cloud Print (for the set of printers I use that have that as their access protocol).
Old Laser printers were brutally poor at modeswitching. You have to send the set of escapes for language selection in exactly the right state in the state machine for it to take effect. If you've left a bit of an old job in a buffer somewhere -- oops, that's 50 pages of raw postscript.
Modern printers that ditched plain-ASCII printing are far more reliable.
I disagree about the old laser printers. I had printcap files that would take dvi2ps postscript just fine. This was CUPS just catting ps output of ghostscript at the printer without setting control codes no matter how it was configured.
My first thought on reading the headline was: hadn't they better get printing working first? I just assumed it still doesn't because after five years or so of not being able to print anything but postscript files to a postscript printer I completely gave up on printing on linux, because like you, no amount of messing with configuration stuff would make it work (I could on rare occasions get CUPS configured on a single machine with one printer, but it was always an incredibly fragile and delicate arrangement that fell to bits when anyone looked at it sideways.)
I started printing on Linux when it switched from the old printcap based tools (which were hard to configure and mostly didn't work) to CUPS. I was an experienced sysadmin, but no amount of configuration could make the old printcap based tools print anything but the text of postscript files to my laser printer.
I believe the OS X implementation of CUPS is rather different from the standard open-source version used on Linux. In particular, if I recall correctly it uses PDF as its internal working format rather than Postscript and a completely different set of printer drivers to the Linux version.
No - it is standard CUPS with some extensions to interact with the MacOS GUI. It runs the same drivers as Linux which is great for old printers or those without MacOS support.
The main change when Apple purchased the project was a license change to allow proprietary drivers when running on OS X.
I suspect you're getting confused with the change from NeXTSTEP to MacOS X where Display PostScript was replaced with a PDF-like system for copyright/licensing reasons.
Maybe someone can explain how this works to me: In the white paper (http://ftp.pwg.org/pub/pwg/BOFs/3d-printing/wd-apple-ipp3d-2...) section 5, it lists a bunch of attributes ("material-type", "filament-retraction-speed", etc.) These are all attributes that would be inputs to a slicer. Furthermore, there are a million such parameters (CUPS will never cover them all), are different between different slicers, are ever-changing, and sometimes undocumented.
Why would cups concern itself with these parameters, versus, for example, just acting as a transport for the actual print file (gcode, x3g, etc.)? I feel like this is akin to having CUPS assemble a PDF, versus just acting as a transport for postscript file that gets printed.
OS X's been using CUPS for a long time and, as other OS X users have noted, doesn't have the reliability problems people are reporting here on Linux. So those problems must have to do with things that aren't directly CUPS related, like possibly an application, PPD, Ghostscript, backend, or network or USB problem. Each distro packages this up a bit differently and with different versions so that could also be part of the inconsistency.
Offtopic: What is currently the best home 3D printer? I am looking for something that produces reasonable level of detail and items that aren't easily destroyed by applying slight rotational forces.
We got a Wan Hao http://3dprint.com/62585/wanhao-usa-duplicator-i3/ for about $400 and it's the best printer we have seen in that price range (part of my job is evaluating 3D printers). I've done a number of detailed, production-quality prints (I make parts for scientific equipment using it).
What's your budget? 3D printers for home use vary in price from a few hundred dollars to many thousands of dollars. Also, they vary quite a bit in terms of the materials they support printing.
If you want one example of a good high end 3D printer for the home market, I'd say take a look at the Form 1+:
Can we first stop making fucking ANY x support depend on the entire CUPS subsystem?
I have a LOT of different computers/VMs that need X in some form, and will never, ever EVER print anything. Why do I need the 10+ CUPS packages to install a minimal desktop environment?
While my comment was a bit glib, new features do have a tendency to introduce complexity & bugs on seemingly entirely unrelated parts of software. If CUPS is going to make a big push on integrating 3d printing, I'd bet you that it causes more than one bug with the normal 2d printing, even if it is a compile-time option.
I just hope that the 3d part of CUPS is easily removable... I'd hate to see it part of the common user experience, CUPS already has a reputation for a complex and bewildering UI as-is.
> While my comment was a bit glib, new features do have a tendency to introduce complexity & bugs on seemingly entirely unrelated parts of software.
This is true. Given CUPS's modularity, I think this won't add too much complexity, though.
> I just hope that the 3d part of CUPS is easily removable... I'd hate to see it part of the common user experience, CUPS already has a reputation for a complex and bewildering UI as-is.
I don't imagine it affecting the normal user experience at all. 3D printers are still printers and presumably configured similarly.
meh, the only similarities between 3d printers and "normal" printers is the word printer in the name and the fact that they are output devices. 3d printers have much more in common with 3 axis CNC machines then with printers. In fact, the control code that many hobbyist 3d printers use is actually based on the control code used by CNC machines.
I thought that too first, but actually they do seem quite similar. Main difference from computers point of view is that paper printers take in postscript and 3d printers take in gcode. Of course the printer itself is completely different but that is all quite opaque to the computer.
If you want to be that pedantic, there is little difference between a monitor and a printer. There are a lot of configuration differences between 3d printers and normal.
