Post edited 7:14 pm – January 8, 2012 by Kurt Pfeifle

---

Adobe published PostScript as a programming and as a "printer language" in 1984, and it stopped developing it 15 years later (beginning of 1999 was publication of PLRM, 3rd edition).

Adobe released the PDF document format in 1993, initially mainly as a way to display and electronically distribute WYSIWYG layouts, but shortly afterwards also promoted it to a "printer language". And indeed, most current PostScript printers are also able to consume PDFs and (directly) print PDF files. Now, nearly 20 years later, the development of the PDF format is still ongoing, and PDF's presence on all OS platforms is ubiquitous.

However, one aspect of PDF's success begs some questions:

• Why is it that most PDF documents whenever they get printed are converted to some other printer language (PostScript, PCL, ESC/P, …even AFP/IPDS!) before they get sent to the output device???
• Why is it that even most PDF-capable printers never see a single job fed to them in PDF format, but instead receive PostScript (or PCL) even when the original document on the user PC was a PDF???
• Why is it that most owners of a PDF-capable printer (I'm ignoring commer- cial printshops for this one) are not even aware that their device can print PDFs directly???
• Why is it that after 18++ years of PDF coming to life this format is still so unpopular as a printer language, while being (or becoming) ubiquitous in (nearly) every other of its fields of use???

(As you can see, I'm obviously not talking about production printing and commercial printing environments here. I have private and general office printing in mind.)

I think I know the answers. But I'm curious if there are a many people on this list who would take a very different view, and what their arguments are … or whether I'm just falling prey to some crazy idea. So my answer to above question is:

PostScript is still more popular as a printer language than PDF….

• …because PostScript provides an officially documented standard way to control all aspects of a print job (via the PPD specification) such as duplex/simplex, media size, input tray, stapling, punching and other output finishings,
• …while PDF does none of this.

You need special, mostly expensive and often proprietary additional third-party software in order to send a PDF to a printer and at the same time keep the same level of job control that you have when using a PostScript or PCL driver.

If a user spools a PDF document to a PDF-capable [footnote] printer, the output may well print fine: but all he/she gets in the end is a wild collection of loose sheets of one-sided printouts instead of the desired result (f.e. booklet, duplex, stapled). And they cannot even request a simple thing like "2 copies, please!" with the Direct PDF Printing technology!

---

[footnote:] Of course, we do not know for sure how robust the PDF-rendering capabilities of such printers are and/or what real fidelity their pageimaging achieves… This is because hardly anybody puts these features under real stress, and hardware vendors never get any customer feedback about it.

---

In PostScript you don''t even need to resort to PPD technology (which allows vendors to implement arbitrary proprietary job control commands), but you still have some basic job controls: because there also are some core language elements which provide control over some of the most frequently used job options ("setpagedevice", since PostScript Level 2 in 1991).

From the top of my head:

Media Selection Parameters:

PageSize, MediaColor, MediaType, MediaWeight, InsertSheet, LeadingEdge, ManualFeed, TraySwitch, [...]

Page Image Placement:

Duplex, Tumble, MirrorPrint, NegativePrint, PageOffset, ImageShift, [...]

Page Delivery:

Collate, Jog, NumCopies, OutputFaceUp, NumCopies, OutputDevice, OutputType, [...]

You even have a rudimentary "Policies" ruleset for handling print requests which ask for features not supported by the target device.

Yes, I know about CIP4 and JDF.

But this will never help to make PDF printing popular with the Joe Does, their office managers and the printers they own or buy newly. CIP4/JDF is for specialists and for production printing only…

So:

• Why don't we push for the inclusion of a simple mechanism into (one of) the next PDF standard(s)?
• A mechanism that handles the 10-20 most frequently used print job options?
• That set of print job options which covers the needs of 80% of all office print jobs?
• A mechanism that defines in a common, standardized way for such tasks?
• Why can't we require that only printers which implement user control over these job options in the specified way may be marketed with a label "Conforming to PDF 2.0 Print Extensions" (or however wants to name the baby)?

So which ones would be the most important job options required for DirectPDF printing in non-production (non-CIP4/JDF) printers?

I think the following basics would not need much discussion, because they largely match what is possible with PostScript Level 2:

• Number of copies
• Collate jobs
• Duplex/Simplex (including tumble/notumble)
• Page size
• Media selection
• Mirror print
• Paper source (tray)
• Scale to fit page size

Maybe people would probably argue about some more essential feature they'd like to include, such as…

• "Secure" print (PIN based or else)
• Print colors as grayscale (for color printers)
• Apply a watermark
• N-up printing
• [...]

In any case, I would not overload the feature set. This new "standard" should be limited only to the most essential job options. The ones which cover 80 or 90 % of your requirements in your office when you have to print out more than one copy containing multiple pages…

In no way should this effort try to even come close to what CIP4/JDF are attempting to do.

I imagine a very simple mechanism, which could be exhaustively documented on less than 20 pages and which at the same time could be implemented rather easily and with little effort of developer man days into existing printer PDF RIPs.

Of course one could invent a new wheel for that: define a few new "comment lines" at the beginning (or the end) of a PDF file carrying the print requirements, or what-have-you…

Luckily, there is already a "standard" mechanism to tell a printing device about requested job options: it's the Printer Job Language (PJL) as specified by HP already decades ago. And a version of it is usually implemented in all PostScript- and PDF-capable devices. However, PJL is riddled with many incompatibilities and vendor-specific extensions. And it does not always work for PDF job formats. (I know it works by and large with Ricoh printers, though.)

So let's try and get an initiative rolling, that defines a small set of important printjob control features as PJL commands:

• which covers the needs of 80-90% of common private and office printjobs;
• which standardizes the PJL command names for this set (we want it named "Duplex", not "EFIduplex");
• which strives to become an official part of the PDF-2.0 specification (or as an extension by the name "PDF Printjob Extension" or some such);
• which requires all conforming viewers to implement the capabilities of reading/writing appropriate PJL header lines to any PDF document so a user can easily control their effects when printing the file;
• which provides an incentive and an easy target to all printer vendors to implement within a relatively short period of time.

I think such an accomplishment would pave the way for PDF to become ubiquitous even for private and office printing tasks.

You know, a few years ago I've met the technical director of an AFP printshop, who was deeply knowledgable in all things AFP/IPDS production printing. His private printer at home was a Ricoh device. When I told him that this model was able to consume PDF, he was completely caught off-guard. At first he didn't even believe me that printers had meanwhile gained the capability of consuming PDF, let alone that his two-year old home office printer was one of these. Of course, I didn't push for him to change is printing routines, knowing that nobody who is used to multi-copy, stapled, duplex printouts would be happy with a collection of simplex sheets…

Had we had, already a few years ago, a simple mechanism of PDF job control such as I propose here now — what could have happened? This guy today probably would be a candidate who gives thoughts about exposing his transactional production printshop to PDF/VT ideas.

But no, he isn't, because PDF Direct Printing is not anything he learned to trust in practise at home.

And no, most people who do use a PDF-capable printer at home or in their offices at work, still don't even know they do.

Let's change this.