Wednesday, 13 June 2012
PCL VS. Postscript
I'm often asked for my opinion on PDLs (Page Description Languages). It's typically a very open ended question; “should you use Postscript or PCL”.
This then seems to spark all sorts of controversy which it shouldn’t. In the end, why do you really care what PDL you use? As long as when you press print your document comes out of the printer properly formatted who really cares how it go there or in what language?
That being said, some PDLs are a little easier to work with post driver or when debugging. Also, if you can limit the number of PDLs in your environment, it should make overall maintenance simpler.
START WITH ONE...
So start with your preferred PDL and add others as you encounter applications or situations where another is required or works better, and don’t fear an environment that is not built around one language, in my experience this is almost impossible. To add to all of this, you probably have other applications where you have no control over the driver and language so you probably have a mixed environment already.
In most environments we would recommend using drivers in the following order (my order) of preference.
Postscript (any version)
It can be argued that Postscript output more accurately represents colours, is more efficient with graphics, and is more consistent from device to device.
Captured output is human readable which makes it easier to interpret and debug. As an example, if a job is printing from the wrong tray, you can capture the output and see what the application/driver has inserted for media source and type. This is useful for problem determination and isolation.
It’s also much easier to view, convert and otherwise post-process then most languages. Tools such as Adobe Acrobat, Ghostscript, GSView and many others can view and convert these files to PDF or other graphical formats. This might not be a requirement in your environment, but with languages like PCL, there are only a few commercial products that would allow for similar post conversion.
Postscript is a double-edged sword with native PS-type applications such as Acrobat Reader. These applications will often recognize that the driver is Postscript and allow for the application to generate the Postscript output and not the driver. The upside is that application release time from clicking print is improved; however, this may come at the cost of compatibility with the printer. One can always disable Postscript pass-through within the printer driver in situations where this is a problem. This will force the application to send the data as GDI to the printer driver, which will then convert to manufacturer specific Postscript and send the data onto the printer.
When Postscript won’t do our fallback is PCL 5.
PCL 5 is not the best choice for graphic intense output; however, with the speed of workstations, networks, and printers, the performance decrease is less these days and the typical user will not notice major issue with colour or graphics quality.
PCL 5 output is, similar to Postscript, human readable (mostly). PCL files can be opened in a typical text editor and commands such as paper orientation, tray selection and paper size easily found. In fact, with a little knowledge (or 3rd party tools) you can systematically walk-through the file and determine exactly what the printer is being told to do. This is useful in debugging and problem isolation.
In terms of post-processing, PCL 5 is a difficult language to convert to something else; however, the post-changing of paper tray selection and other elements is simple in that a search and replace for that value can be applied.
It should be recognized that PCL 6 is not an updated version of PCL 5 but rather a completely different language. As such, most manufactures that includes PCL, include both PCL 5 and PCL 6 (sometimes referred to by its original name PCL XL).
We see this as a last resort language. Although it has resolved many of the potential downfalls of PCL 5 including better graphics, colour, and performance, it resolves these at a significant cost. The output created by the printer drivers is not human readable. It is a compiled executable that is run on the printer. This makes debugging and post-processing nearly impossible without commercial 3rd party tools.
If Postscript and PCL 5 will not work with a particular application and PCL 6 does, our first statement regarding printer drivers holds true, in the end it doesn’t really matter.
This article was put together by a friend of PWW - Doug Anderson, President of Ballistic Echo.