Eliminate pre-printed stationery without program changes
Do you use pre-printed paper stock (a.k.a. letterhead or business stationery) when printing from SAP or Windows applications? If you do, and have been looking for a way to eliminate this requirement, read on!
Color printing: then and now
Businesses have long used color logos and other graphic features on their business documents to reinforce their branding and improve document usability. In the past, companies often used pre-printed stationery to accomplish these goals. This made sense, as color printers were rare, expensive, and not very reliable. Since most normal office printers could only print in black-and-white, it was more cost-effective to pre-print any color features directly on the paper stock itself.
Today, color printers are much more reliable and relatively inexpensive, making pre-printed stationery the more costly option. The expense is not only in the external costs of producing pre-printed stock, but also the costs of ordering, storing, shipping, and transporting this paper to the locations where it is needed. On top of this is the cost of updating obsolete forms and disposing of the outdated stock. All of these are manual processes, and prone to failure at some point.
Such factors make the switch to color printer deployment a logical one. But these cost justifications may go out the window if the programs that print the documents require coding changes to support that change. To understand why, let’s review how the “pre-printed stationery method” works in the real world.
The complexities of tray selection
So how do people print using pre-printed stationary? Generally, they will load up the company letterhead or other colored stock into a particular printer input tray as agreed upon with an application programmer and put plain paper in the other tray. The programmer will then then code the application to select (for example) printer Tray 1 for all prints requiring letterhead stock and Tray 2 for normal paper.
Usually it’s the first page of each customer printout that requires the all-important pre-printed stock. However, if a single print job contains data for more than one customer, then the “tray pull selection” code will appear more than once throughout the job. Additional complications arise because different printer models and manufacturers use different “tray numbers” for the same tray. So for example, Tray 1 on an HP may require a very different tray selection code in the PDL (Page Description Language) than Tray 1 on a Ricoh device. For environments with multiple printer types, this means more work for the programmer.
Bringing order to chaos
LRS’ VPSX solution simplifies this process by “de-coupling” the business application from the physical print device. Using LRS Data Transforms, LRS software can intercept the input tray codes in a PDL, optionally changing them to a different tray. Moreover, it can interpret a request for pre-printed letterhead stock and instead send an electronic graphical overlay to be printed on plain paper.
Sound simple? It is! To implement, you create a new ‘filter’ for the printer definition, tell the filter which overlay belongs to which (logical) tray, and what model of printer you are using. Then, just scan a current pre-printed form or use a design tool to create the new overlay and save it on the VPSX server where the Transform can access it, and you’re done. The filter definition is responsible for calling the Transform process with the required parameters (e.g., Tray number and overlay location) together with printer model type.
When rolling out this new letterhead printing approach, you can implement it on a printer by printer basis or location by location, changing to the new method as your supplies of pre-printed stock run out.
Other uses of tray pulls
If you are printing for multiple clients and require a different form for each, even this can be easily achieved through the use of VPSX’s filter technology. For simplicity’s sake, you should place the name of the client you are printing for into the title of the printout. This enables the filter to easily pick up this extra information and select the required overlay, for example, by matching the client name found in the title to the file name or directory where it is stored.
Sometimes special codes are also required for other papers to be inserted into the print stream (for example, a money transfer form). Again, this will come via a dedicated tray pull, which is easy to implement through the filter. Same goes for prints where the second and subsequent pages simply need the addition of some footer information, as again that’s loaded into a specific input tray and is not a major issue.
As always, for advice and help when implementing these or other printing-related changes, feel free to contact your local LRS printing expert. They will be glad to help you construct the required filter or determine the best solution to your printing challenge.