JetForm/Accelio/Adobe Central is as fast to print as it is because it does not send a completed and rendered raster to the printer. All that the printer gets is, in the case of HP’s, PCL. It uses the smarts built into the printer itself to RIP the code to pixels for printing. As a result, the files sent down the line are much, much smaller than any spool you’ll ever see come from a Windows (for example) application.

RIP – Raster Image Processing or Raster Image Processor. This is the hardware or software responsible for taking the printing commands – things like lines, boxes and text – and turning them into pixels (a raster image) suitable for printing to paper. Every single laser and inkjet printer in the World uses a RIP of one type or another, and the best and fastest RIPs are almost always in hardware.

Raster – A bitmap image, meaning one that is made of pixels.

HP-PCL – Hewlett-Packard Printer Control Language. This is HP’s own Page Description Language intended to be used with laser printers. Though not as accurate or quite as flexible as Adobe Postscript, PCL is an excellent language which contains everything needed for business and other utility printing. One strong difference from Postscript is that PCL is a binary language as is very compact, while Postscript is actually a language and intended to be human-readable.

Smaller files means faster transit, and faster transit means faster first-page-out. The RIP in the printer is also highly-tuned to this task, so even on a relatively poor network connection we can keep printing at full speed.

The problem with these cheaper printers is that they don’t have any of these smarts built into them. They rely on the host computer doing the printing to RIP the printer data to a raster that is then sent to what is essentially just the print engine.

HP calls this “Host-based” printing. Check out the 1022n spec and see how many times it says that.

Printers like this are, generally, a bad idea anyway. They can’t be used cross-platform, and when the next OS comes out and driver support goes away…you’ve got nothing. I had a Canon laser once that worked like this, and when Windows XP came along, it suddenly became useless to me.

To get around this, you’ll have to configure your form(s) to be able to print with the HP Windows Driver. You do that from the “Presentment Targets” menu, and I don’t advise it. Primarily because then everything slows down, and you don’t want that.

If you have a fleet of these printers, you will no doubt have to bite the bullet and switch to the Windows driver. If you only have one to test, I’m sorry to say you won’t want to be saving this money…buy higher models that have the built-in RIPs.

If your logging levels are turned all the way up, you can get insane improvements in speed with very little effort and only a teensy amount of risk. So what are you waiting for?

There is, in general, only one situation where you need to turn up your logging level: When you are counting pages to print “Page 1 of 10″, “2 of 10″ and so forth. Your first printing pass on one of these needs to have logging turned up enough to catch the trace statements that record the numbers, so follow my instructions carefully if you need this. (There are other uses, but I’m not going into all of them now.)

There are three places that you can set the logging level. These are:
   1. In the JFMERGE.INI file. This affects everything globally, unless overridden farther down the line.
   2. On a task line in the JMD*. This affects only that task.
   3. On a ^JOB line, which affects that job and all tasks it might run.

I recommend setting your JFMERGE.INI file to produce as little logging as possible, and to only pass commands to increase it in your tasks that require it. In my opinion, this gives the most control of any approach you might take as the changes you make are pinpoint specific to where they need to be.

I shouldn’t have to say this, but if you’re not familiar with editing .INI files and/or you don’t know where your JFMERGE.INI file is, you might need to get some help.

To edit your JFMERGE.INI file, open it up in Notepad or another text editor (I use UltraEdit) and look for the [JetForm] section. It should be near the top.

I recommend editing your INI files and your JMD in a text editor instead of in the Central Control application. I find this to be much easier and more straightforward, and it carries no greater risk than editing in Control. Just remember to always take a backup of your current, working file before editing it.

Make these two edits:
   1. Set the Verbosity entry to be 40
   2. Set the EventTraceLevel entry to be 100 (It should already be 100 if it was never changed.)
   (This combination effectively switches off the most logging for maximum speed.)

Save the INI file and your changes are immediately in effect.

Now to edit your JMD. This is where you need to be careful with your logging levels if you’re doing page counting. And, whatever you do, make a copy of your JMD somewhere else before editing it…just in case you need to roll it back.

For this exercise, we’re only worried about editing Tasks in the JMD. These control the commands that are sent to JFMERGE as individual processes take place, so if we need to increase logging for something then this is the place to do it.

Your task lines will all begin with !x – you should go through all your tasks (search if you like) looking for -v and -n, and you should remove them completely from tasks that do not require them.

Here’s the Golden Rule about when you need to turn your logging up: Does the task contain the -atf command? If it does, you’re sending information to a trace file, possibly for page counting, but it could be for anything. In order for trace to work, you have to keep the verbosity set to zero. If there is no tracing going on, there are very few instances where log files from production systems have other uses.

So you might have a task like this:

That you would change to have the additional -v0 in it:

Add that -v0 on any tasks that have that -atf command in there. If you have tasks that don’t do traces and don’t need to have increased logging for whatever reason, don’t add a -v or a -n back into them.

If you have problems down the road, all you now need to do to increase the amount of logging system-wide is to edit your JFMERGE.INI and set Verbosity back to zero for as long as you need the extra information. Then changing it back is a snap!

Questions? Leave a comment!

*What is the JMD?
The JMD is the Job Management Database. Simply put, it is a text file – editable in Notepad or anything else – named JFSERVER.JMD that resides in your /server directory (or directories) that controls what Central will do when it sees a particular ^JOB line on an incoming file.