Slashdot Mirror
*NIX Ripping Solutions For Plotters
haogemenr writes: "I work in an all Apple architecture firm, but we have a Linux box that primarily functions as a DSL router. The options for large format plotter drivers in the Macintosh world are few and relatively expensive. PostScript output devices are a great, but expensive solution and HP doesn't provide any Mac-friendly drivers for non-PostScript plotters. What are the *nix solutions? You can write PostScript from CAD application using a generic PostScript driver, but converting PostScript to an RTL file or HPGL2 file is necessary for lots of older plotters.
I've heard of an application named makertl, but I haven't been able to find it anywhere.
What do Unix folks use for large format image processing?"
Well these are *nix solutions, but they may work for your office.
MacPlot is a commecial product from www.microspot.co.uk which can act as a network based RIP server for the mac...
HP has their own RIP software for windows that is packaged with the HP 500 PS. (There was also a version for the 455CA and 488).
There is a company that sells some very high end RIP software called PosterJet. (www.posterjet.de) which I belive will turn a windows box into a RIP server.
Of course, the best solution would be to use a printer that was supported on the Mac!!!
I know the people that do VectorWorks (probably the best all around Mac CAD package) made a viewer available for free. Just download the viewer onto a windows machine and use the HP drivers. Hell, this would probably work under WINE as well.
If your not using VectorWorks, you could also just print to a PDF file on a network voulme (print2pdf from www.jwwalker.com is great for this), and again have a windows machine just output and delete everything in that directory every few minutes.
Jeez!
First off, ditch all the Macs.
It's a wonder people even bother with Ask Slashdot when they get "helpful" responses like this.
I did a google search, and ps2hpgl can be downloaded from mathworks.com. I guess that was too much work.
Aside from that, I think CUPS has some hooks for plotters, but I've never looked into it seriously.
Get a commercial RIP and plotter combination made to work together that has client drivers for the kinds of machines you print from. In the world of graphics printers and RIP units, that almost always means Postscript. Live with it and budget for it and stop trying to find novel and unusual uses for Linux for its own sake in a running business. Use Linux when Linux is the right solution for something.
While you might be able to build your own "solution" with Ghostscript and who knows what else, you're going to be on your own if lines don't intersect the way they're supposed to and labels show up in the wrong font and layers aren't rendered in the right z-order. I'll bet architects, engineers and drafters don't like that and won't be as excited as you are about your $6000 "savings" if they're sending jobs over to Kinko's at ten at night because the RIP on their $8000 plotter is an unsupported piece of garbage sending generic Postscript or converted HPGL to a fussy device that works best with output massaged to address its quirks.
Like I said, pick a solution built around a plotter that meets the users' needs and a supported RIP solution that has a supported driver for that very plotter and client drivers, and PPDs for the OS of the machines that will be outputting to it. If the only things that meet these criteria use Postscript, then welcome to the world of Postscript. While you're at it, if it's a critical device for the running of the business, get a same-day on-site support contract for both pieces.
The only advice I'll give beyond that is to get a RIP device built around an embedded device OS or Unix (Linux, BSD, QNX, Mac OS X, whatever), or at least an NT variant. You can expect reasonable stability and uptime that way. I'd avoid any RIP devices or software built around MacOS 8.x and 9.x. In my experience they freeze up far too often. No RIP should ever freeze, but while once every few weeks is manageable, daily (or worse) freezes and crashes are a bit much. You don't want to become too familiar with your RIP vendor's regional field support engineer.
The choice of OS behind a RIP device should have nothing to do with the OS of the client machines; it's just an appliance connected to your printer. A RIP device is single-purpose, and any expectation of using a RIP to do double duty as something else is a terrible, terrible idea under most normal circumstances.
When should you use free stuff on Linux for this? Go for it if you find a solution with accompanying Mac drivers that has an active user community and mailing lists filled with enthusiastic testimonials from people who use it commercially in a production environment with the very plotter you plan to use and output from Macs running a similar set of applications.
We have two RIP servers in our office, both made and packaged by Colorbus. One is NT based and runs on what looks to be a rebadged Intergraph/SGI Zx10. The other is unix based and is a bit faster, it runs on an SGI O2 (although most of the work is being done by a PCI card). I have no idea what these cost, but I'd imagine they wern't cheap...
Large-format plotters are few and relatively expensive. Why on earth would you spend $100,000 on a plotter and then become all cheap-ass when it came time to hook it up to a plot server?
Shell out the money for something that will work properly. Don't waste your employer's time and money trying to find an open-source "solution", and, if there's a payware UNIX solution, make sure it's fully supported by your plotter vendor.
Do not skimp on stuff that matters. It's like buying a Ferrari but not being able to afford the racing gasoline.
- A.P.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
Ghostscript (gs) basically converts postscript to a bitmap, then uses whatever drivers it has to convert that to the needed format.
This works reasonably well for pictures and stuff, but for a plotter this would be iffy at best. When you actually printed it out, rather than drawing the lines as designed, the pen would trace a line across the page, go down a tiny bit, trace another line, go down a tiny bit, trace another line, etc. As needed, the pen would be raised and dropped, probably drawing lots of dots. Eventually, it would probably draw the picture ok, but it could take hours, and would wear out your plotter.
This all assumes that what I know about plotters hasn't become totally obsolete. When I worked with plotters like 15 years ago, that's how they worked. Maybe they're fancier now.
To put this in video game terms -- think a Vectrex vs an Atari 2600. The Vectrex draws lines, and they look perfect (in arcade terms, think the original Star Wars game, think Asteroids, Star Castles.) The 2600 drew bitmaps -- less precise, but more flexible (think the arcade Space Invaders.)
Something tells me it ain't cheap, but this is swell and runs on Unix. My company had a loaner on an older RS6000 running AIX.
I like music