> In > general, are most printers postscript capable, if that's the term.
Most modern laser printers do, unless they're really, really inexpensive. Any laser printer made in the last 2-3 years is almost certain to have both PCL and PostScript personalities -- about the only things that don't do PostScript these days are the inkjet printers and even they're getting the capability fairly quickly (PostScript is a lot better about handling color output). PostScript is basically a embedded Forth interpreter with some printing-specific verbs predefined, so it's really a full-scale programming language for talking about document imaging -- what you are doing in preparing PostScript output is sending the printer a program describing what the page should look like and relying on the printer to execute it. Providing PostScript generally requires a little bit more horsepower in the printer to execute the program, which tends to cost a bit more (as well as the license tax to Adobe for Real Genuine Adobe PostScript (tm) if you want to brand it as PostScript (tm)). GhostScript is a independent implementation from the published specification, and thus doesn't incur the license tax. Pretty much any printer that supports both Macs and PCs does PostScript, as the Apple folks blew off PCL support entirely and went straight to PostScript. [If you have a spare week or two, I'll send you a ray tracing program written in PostScript (allows you to render shiny glass balls using nothing but the CPU in your printer. Guaranteed to make you the most unpopular person in your entire office when you monopolize the laser printer for DAYS at a time to produce single pages of output....8-)). ] BTW, a nice side effect of the "send a program and let the printer render it" approach is that you're no longer tied to a specific resolution or device vendor for printout. ALL the big heavy-duty high-volume printers printers like the Xerox Docuprints and the Agfa presses, etc speak PostScript, so you can proof on cheap printers at 600 dpi and use the exact same file to render at 4800 dpi on the big boys when you're ready to do the million copy run. That's why the graphic arts and really high-quality imaging people prefer PostScript. PDF is essentially PostScript with some additional structure to handle browsing. PCL fails horribly for this application. It just wasn't designed for it. > Also, > can you mix PCL code with Postscript? I think the client adds PCL code > within the print stream to bold or underline certain words in a printed > report. Generally, no, although some printers permit you to change personalities within the scope of a print run (genuine HP printers usually allow it). For HP printers, you set the personality of the printer using some command strings -- install an HP PostScript driver on your Windows box and print a document to a file. The ==JDK stuff you see at the beginning of the print file is the magic stuff to set the printer personality for the print job. If the applications are hardcoding PCL strings in the middle, then you're gonna be stuck with hardware dependencies. On the other hand, you can easily interpret standard carriage control as part of your PostScript program (the RSCS line driver for PostScript printers does exactly that), so your application can go back to using -,+, space, 1, 0, etc to control line spacing, overstrike, etc and not have to worry about coding specifics into the print stream. There's no reason why you can't have the same printer defined both as a PostScript and as a PCL printer, though. Use the PostScript one for normal stuff going forward, and use the PCL definition as a transitional step until your applications stop doing device-specific things. One other approach to your problem occurred to me during lunch -- most PCL printers do support downloadable fonts, and there are Windows applications that allow you to create downloadable PCL font files. You could configure the CUPS implementation I suggested to download a PCL font of the appropriate size and glyph characteristics to the printer -- perhaps as part of your separator page definition -- and mark it resident (see your printer's PCL programming guide for how to do this). Once you've done this once (per printer powerup), you can select the font using the normal PCL escape strings within your print job just as if it were a built-in font. That approach would work with both inkjet and laser PCL printers, albeit it tends to waste a bunch of bandwidth to the printer downloading the font multiple times (PCL isn't smart enough to be able to interrogate whether a font is defined and not download the font if it's already there). The side effect to downloadable fonts is that they consume memory in the printer that is otherwise available for buffering print data. If the page is sufficiently complex, you can get situations where the printer is unable to buffer a full page of output and just tosses the part it can't handle (this used to be very common with the original Laserjets and Laserjet II printers, but hasn't been much of a problem recently -- at least if we're talking about printers that aren't the totally cheap bottom-of-the-line units). They also go away with a power-cycle of the printer, so you pretty much have to assume you're going to send the font down to the printer with every job.
