When printing PDF files in Adobe Acrobat or Acrobat Reader, the jobs are not showing up on the Release Station or terminal. You may also get inconsistent results when printing from Blueprint Policy Print/Pharos Uniprint and this application.

Blog Post created by toleary on Aug 1, 2013

This article applies to both Pharos Uniprint and Pharos Blueprint using PCounter.exe 8.2.6129.0 and lower.

The Portable Document Format, or PDF, originally introduced by Adobe Systems, Inc., has become an almost ubiquitous file format for the distribution of information intended for web, mobile devices, or for print. And while the PDF document can be printed to just about any type of printer, it has a special affinity - a connection - to PostScript printers, as the two share a very common ground.

Along with every great step in the development of the PDF format, Adobe Systems releases a new version of the Adobe Acrobat product line. In spite of the functional differences between the Reader, Standard, and Professional editions of Adobe Acrobat, they all share common function in terms of PDF file display, navigation, and basic printing. Which brings us back to PostScript. Adobe has engineered a good chunk of their PostScript driver technology into the Acrobat product line. This was done, primarily, so that Acrobat can reproduce, as mach as the printer and its driver will allow, the PDF file on any print device with equal fidelity. On non-PostScript devices, Acrobat pre-renders as much of the file contents as possible so that the driver isn't doing it. On PostScript devices, Acrobat generates much of the job code so that the driver isn't doing it (the theme: Acrobat trusts the driver to understand the printer's capabilities, but not to convert its PDF file). Because some PDF files can be quite complex, Adobe builds in some optimization functions to make the PostScript file as efficient as possible.

Which brings us to ... well, us. Our current PCounter is good at what it does and can accommodate many different print languages. But the current version (8.2.6129.0) and previous versions may not handle an option in one of Acrobat's PostScrips functions for optimization: sending fonts (and other resources) well. The default setting is "Send as Range." This setting inserts the font at the beginning of the page that it is needed, and then causes the font to be removed from printer memory after the page has printed. With some print drivers, the PCounter may fault with an Unknown, undefined error and may call out a font name if parsed with the Page Counter Tester. An example of this dialog, found in Print > Advanced is attached to this article.

However, the setting "Send at Start" will work when applied with problem drivers or PDF files. This setting uses the most memory (as all fonts in the document are sent at the beginning of the document and retained until the entire file is printed), but is the most compatible. This setting can be made permanent for Adobe Acrobat Reader by opening the Registry key HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\<version>\Originals and adding a DWORD called bSavePSVM and giving it a value of 0. If the location is using an edition of the Adobe Acrobat product like Standard or Professional, the Registry key is HKEY_CURRENT_USER\Software\Adobe\Adobe Acrobat\<version>\Originals. The same DWORD and value apply.

PCounter's inability to handle PostScript code from Adobe Acrobat with the "Send as Range" option enabled for some printer drivers has been resolved. A new PCounter.exe and support files can be downloaded from  Pharos Systems' FilesAnywhere. To upgrade, stop the Pharos Print Server service on the print server and extract the files into the Pharos\Bin folder, overwriting any existing file. When finished, start the Pharos Print Server service.

For Further Reading: Adobe has a KB article describing other "features" of the "Send as Range" option. Read it at