Hewlett-Packard Appliance Printing Software Development Kit

 

Best Practices For 
Optimal Printing

 


 

 

Version Date Comments
2.0.0 11.29.00 Version 2.0.0 documentation reflects code changes from code Version 1.1.0. (Note: Documentation and code version numbers are designed to be independent of each other, and may not agree.)

 

 

 

Notice

The information contained in this document is subject to change without notice.

Hewlett-Packard makes no warranty of any kind with regard to this material, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose.  Hewlett-Packard shall not be liable for errors contained herein or for incidental or consequential damages in connection with the furnishing, performance, or use of this material.

All SDK documentation included in this list, received with the Hewlett-Packard Appliance Printing Software Development Kit, or received at a later date as a result of communication with any Hewlett-Packard employee regarding the Hewlett-Packard Appliance Printing Software Development Kit, is Hewlett-Packard "confidential" information.

Licensee shall not export or re-export the Hewlett-Packard documentation, or copies or variations thereof. Licensee may use Hewlett-Packard documentation only to develop Licensee Printer Drivers for exclusive use only on Hewlett-Packard printers.

Licensee shall assure that all Hewlett-Packard Software and all documentation based on Hewlett-Packard Documentation include the following notice:

"Copyright © [year]

Hewlett-Packard Company.

All Rights Reserved."

Hewlett-Packard Documentation has been developed entirely at private expense and is provided as "Commercial Computer Software" or "restricted computer software." Use, duplication or disclosure by the US Government or a US Government subcontractor is subject to the restrictions set forth in subparagraph (c) (1) (ii) of the Rights in Technical Data and Computer Software clauses in DFARS 252.227-7013 or as set forth in subparagraph (c) (1) and (2) of the Commercial Computer Software-Restricted Rights clauses in FAR 52.227-19, as applicable. The Contractor is Hewlett-Packard Company, 3000 Hanover Street, Palo Alto, California 94304.

Copyright ă 2000

Hewlett-Packard Company.

All rights reserved.

 

Best Practices for Optimal Printing

 

Introduction

It is easy to make the mistake of assuming that the image on the screen will automatically transfer to the printed page, printing an identical image as to what is on the screen. It does not.. This ‘screen shot’ approach will not achieve the look and feel that a user expects when holding printed output in his/her hand, and comparing that same information to what is on the TV screen.

The main differences between a video display (TV/monitor) and a printout of that display, are in image resolution levels and formatting for correct text size and color.

 

Problem: Image/Text Resolution

A higher resolution image (more pixels per inch) means a higher quality image. Therefore it is not surprising that when image data is compressed (such as compressing a multi-megabyte bitmap image down to a 125k JPEG image,) some amount of data (i.e. quality) loss occurs in the process. In other words, higher compression leads to a greater quality degradation. On the opposite end of the spectrum, low resolution compressed images may look fine on a video screen at 72 dpi, but will not look very good after they have been scaled back up to the 300 dpi requirements of the printer. The images will be blocky – a curved line for instance will not be smooth but instead have a stair-step appearance. Text appears to suffer more than images because smaller objects rely more on the precision of high resolution, and while a low resolution image may simply have poor print quality, low resolution text may become unreadable.

Best Practice: 

Use the highest quality images available when printing. The ability to deliver this depends on the capabilities of the host system, but the same image used by the display does not have to be the same one used for printing. For example, the server for an internet device may compress image data to improve download speed. The device itself may receive the image data and ‘down-sample’ the image even further, essentially throwing away data to fit the 72 dpi screen. In this case, it would be desirable to re-request the uncompressed version of this image when formatting for the higher resolution printed page. Go back to the original image data and ask that the page be re-formatted for printing, rather than simply passing off the 72 dpi screen page to the printer driver. 

For text, if the device simply has a set of stored raster fonts optimized for screen resolution, the developer should make use of the printer’s high-resolution built-in fonts. (Refer to Device Based Fonts for more information.) Alternately, if the device has a font rendering engine, the text for the printed page should be re-rendered through the font engine at the higher resolution when formatting the page for printing. Text rendered at 72 dpi screen quality and then passed to the printer driver will produce the same poor quality as stored 72 dpi raster fonts. The font engine is a powerful tool – take advantage of it!

 

Problem: Formatting and Layout for the Screen vs. the Printer

Reading text on a television screen from across the room or even from an LCD screen attached to the phone is different from reading text on the printed page. Passing a ‘page’ of data optimized for the phone or television screen directly to the printer will produce a printed page which is WYSIWYG ("What You See Is What You Get,) but not what the user expects. The news article the user prints from his/her favorite on-line news service should not be 5 pages of BIG text if that same article would have taken one page in the local newspaper. 

 

Best Practice: 

Normal text should be about 10 to 12 points in size and take advantage of the full paper size. A system with a 40 character LCD display may now have twice that width in which to format the information. A TV/internet browser will now have much more text displayed on a page. As such, care must be taken to wrap text correctly around images. Actually, smaller text allows more precise placement and should wrap more easily around other objects.

Be sure to take into account page and text colors. The printed page by default is white. But light colored text on a black background is common for TV based systems as it reduces noise and is generally easier to read. Laying down all the black ink on the printed page to reproduce this effect will certainly irritate the user who is waiting for all that ink to dry, and who must now go out and buy a new ink cartridge after printing relatively few print jobs. Take note of the change in background and text when choosing text color. White text will obviously not show up on a white background and even yellow text will be extremely difficult to read. Choose text colors that will contrast appropriately with the background. The system may make it an option to print backgrounds, as some web pages are designed such that the background image is an integral part of the page. If this option is chosen, we suggest the logic exists to not re-map the text color. (Mapping white text to black while printing a dark background would lead to the same problem of printing white text on the white page.) 

One final word of warning, if the ability to print page backgrounds is allowed, it should not be the default. Most backgrounds are extraneous to the information the user is printing.

 

Problem: Clipping to the Printed Page

A web page is usually formatted as one long page with text and graphics intermingled as appropriate. The printed page unfortunately has physical limits to its width and length. It is entirely possible and probable that while printing multi-page documents, text or images could be cut in half between pages.

 

Best Practice: 

Do the best you can. No easy set of rules exists to solve this problem in all scenarios. Be aware of how much space remains on the current page. The printable width and height of the page are available via the PrintContext object. 

Here’s a simple calculation to give you the input height (number of your rasters) that will fit on a printed page:

            InputHeight = PrintHeight/ (PrintWidth/InputWidth)

(PrintWidth/InputWidth) gives the scaling factor for the page. This value is then divided into the PrintHeight to supply the number of input rows. Tracking the number of rasters you’ve imaged to a given location will allow you to correspondingly track the amount of space remaining on the page.

Implement a "look-ahead" region so that text that would normally be clipped is moved to the next page. Images can be treated the same way, though certainly some images may have to be clipped in order to maintain proper formatting. A very long image for instance, would require clipping, but smaller images may be ‘nudged one way or the other to be kept intact. Certainly text is the easier and more critical of the objects to not have clipped.

[Back to top]