How do I send data to a modern printer? PDF, PostScript, HPGL, etc

Question

I am trying to understand my options for communicating programmatically with a printer to get something printed from application software. In other words, what happens when the user tells my application they want to print something. I understand the way it worked in the "old days", and am trying to understand the more complex modern world.

In the old days, there were two main types of printers: HP printers that understood HPGL and Postscript printers. So, you could send your print out in either of those two languages and the printer would convert your code to dots on the page. You could also embed a bitmap as binary data. For example, in HPGL (or PCL) you could give a command that would basically says "please print this bitmap, and here is the raster data" followed by a gigantic blob of binary data. Obviously if you did this the amount of data going to the printer would be a lot more and could choke the printer. Postscript had the same ability. If you printed text, you could tell the printer to print text "xyz" in font TimesNewRoman (or whatever) and the printer would calculate all the dots for you (which meant the printer had to know the font, or you had to download the font to the printer ahead of time).

Now, as I understand the PDF format it is similar to Postscript, but it is not a language like Postscript and can only include "objects". So, for example, in Postscript you can make a loop and say "print this circle 50,000 times", moving its exact location around. In PDF my understanding is that you can't do this, you have to specify each and every circle as a separate "object".

So, how do modern printers work? Can I still send HPGL/PCL to a printer? Are all printers now standardized on Postscript? If so, does that mean my best option is to generate Postscript and then send that raw to the printer? If I do send Postscript, do I have to tell the printer somehow that it is Postscript somehow?

In Windows, I know the "standard" way to print, which is to query device capabilities and request a device context, then you can draw lines, shapes and text using Windows calls on that context. However, obviously this is extremely primitive compared to Postscript (or HPGL/PCL). Is there a way I can either communicate directly with the printer driver, or tell Windows: "here is my Postscript code, please pass it to the printer for printing"?

Answer 1

'So, for example, in Postscript you can make a loop and say "print this circle 50,000 times", moving its exact location around. In PDF my understanding is that you can't do this, you have to specify each and every circle as a separate "object".'

Actually, the truth is a bit more towards the middle ground in between the two extremes you described.

1. It's true: unlike PostScript, PDF is not a programming language (let alone a Turing-complete one), and you cannot define "loops".

2. But also, you do not have to specify each and every circle (or embedded image, or other graphical object) separately. You can well define how to draw a circle (or image, or whatever) once, and then re-use that definition in other spots of the page or the PDF document. This is called "referencing an object". When you re-use an object, you can set different of its properties differently (color, scaling, rotation) by changing some current "enviromental" definitions (such as the graphics state which includes the CTM, the current transformation matrix).

---

About some of your other points:

• No, there never were only two types of printers, HPGL and PostScript.

• Even in the olden days, there were a dozen or so different 'printer languages'. PCL was more popular than HPGL even. Not to forget all the proprietary inventions of different printer languages. Ever heard of AFP, Advanced Function Printing? This language printed -- and still prints! -- more sheets of paper than PostScript ever did. It's no longer proprietary, but it was invented by IBM for host printing laaaarge runs of variable data, for billing purposes mainly... Ever heard of ESC/P? KPDL? XPS?

• Yes, you can still send HPGL to a printer -- but not to every printer. The printer has always to be empowered for at least one of the languages you are able to generate and send off.

• Yes, there are printer models nowadays which can consume PDF directly. But they are still not the predominant type. Some of them "cheat" and still have as their main built-in interpreter a PostScript engine: these take the PDF and silently convert it to PostScript first. Others can process PDF without the fallback to PostScript.

---

'In Windows, I know the "standard" way to print, which is to query device capabilities and request a device context, then you can draw lines, shapes and text using Windows calls on that context.'

Don't assume that the term 'device context' does mean that Windows talks to the printer hardware directly in order to query the capabilities and request the device context. Sometimes it does, sometimes not. It always relies on some software called a 'printer driver' (which also controls which printer language to print data should be converted to). The printer driver may be able to query the device and ask "Do you have a duplexer unit? Do you have a stapling device?" and then generate the required device context itself for the job.

Only a very modern approach, IPP Everywhere, developed by the 'Printer Working Group', will be able to get rid of most of what the olden model-specific printer drivers had to do, and will start to rely mostly on direct interrogation of the device before 'driverlessly' finalizing the exact print data to be passed to the physical device.

But IPP Everywhere is not yet widely popular, neither with vendors, nor with admins, nor with users. But it will, once the PCs are forgotten and 95% of computing devices will be super-mobile...

• Short Reading: IPP Everywhere FAQ