Embedded solutions

The PDL code must run on the hardware that you’ve selected for its price/performance characteristics. The CPU/SOC and associated hardware component cost is a significant part of your bill of materials, but your choice depends on many factors including volume, device performance, power consumption requirements etc.

That may lead to selection of an ARM-based SOC from Conexant or Marvell for a home or SOHO device, or a CPU from Freescale or Intel for a workgroup or enterprise device.

It must also run on your chosen operating system. If you’re not building up a complete new product line you may already have a whole pile of printer management system components that were written for a specific operating system.

Re-writing them (or even just re-testing) all of that to move to a different OS would be time-consuming and expensive.

You probably have a clear idea of the PDLs that you need to have supported, which may depend on the market segment that you’re intending your new printers for.

If you’re in the SOHO space and migrating from raster-only devices (rendering in the printer driver), then you may only need PCL. If you’re aiming for enterprise level devices you’ll probably also need PostScript. In either case there’s an increasing demand for PDF support because of the desire to print from USB sticks etc.

It’s also possible that Windows 8 will re-invigorate interest in XPS. So in some cases you may need to support at least four PDLs, but integrating different code bases for each would be complex, take more ROM, and may lead to slow first-page-out times if consecutive jobs use different PDLs.

You’re building the printer hardware itself for a specific target print speed. You want a PDL that will drive that engine at that target performance, especially now ISO 24734 defines how performance figures must be reported … but it’s not viable to just throw an expensive processor and huge quantities of RAM onto the controller because that would make your margins (or the printer price) unattractive.

Both RAM and ROM add to your BOM so a small footprint is desirable (with varying emphasis on this from home to enterprise printers).

If you already have specialized hardware to assist with high-speed page processing you may wish to be able to integrate it on your next platform; or you may prefer to use a PDL supplier with a product that can achieve your performance goals without requiring that assistance.

You’ll also have a target quality specification, measured as compatibility against common creation applications, conformance with the PDL specifications, compliance against widely used test suites, accurate and pleasing colour reproduction, legible text even at small sizes.

Unless you’re new to the PDL printer market you probably already have a contract in place with a font supplier, so any new PDL vendor’s solution must work with those fonts.

That might be Monotype Imaging’s UFST using Microtype format fonts, or Font Fusion from Bitstream, or you might be sourcing my fonts as TrueType, OpenType or PostScript Type 1. It must work for the scripts used in all of my target markets, including Japanese, Chinese, Korean, Arabic, Hebrew etc

In the same way, you may already have a contract in place with a printer driver vendor and may want to maintain the same look and feel so your users are at home with the new models.

You therefore need to know that the driver and PDL vendors can work together to provide optimal performance and quality.

And most of all, you need to be confident that your supplier understands what you’re trying to achieve and all the challenges of getting an embedded solution into the market.