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.
Hewlett-Packard has tested the Hewlett-Packard Appliance Printing Software Development Kit (SDK) code prior to its release. As such, the developer does not need to test the SDK code, but rather their implementation of the printer driver using the SDK code set. Hewlett-Packard suggests using 3 printer models to thoroughly test the printer driver: the 640, the 840, and one printer from the 900 family series. The suggested testing can be broken into the following testing categories:
During the development cycle, developers are responsible for testing their implementation of the printer driver for compatibility with their host systems. In situations where it makes sense, the testing should include:
Setup – Connecting the printer to the host system, making sure it is recognized, and can be printed to.
Output correctness - Formatting, page-break handling, text/graphics overlay.
Printscreen –
This may be optional. In addition to the normal
prints, it is important to do a printscreen if the device supports it.
Supported paper sizes - Letter, A4, Legal, Photo.
Printing configurations - Exercising available UI controls for printing.
Help system – Ensure Help is accessible; all links take the user to the proper help page, help content is correct, etc.
UI Controls – Verify all UI controls are working properly; i.e. Print Mode sets the proper output mode, warnings and errors are communicated properly, etc..
Memory resources – Confirm that memory is being cleaned up after print jobs complete, print jobs are canceled, etc..
Error Handling testing checks the driver’s response to unexpected external events. Testing should include the following user scenarios, of which there are two possible user responses: the user cancels the job when an error dialog appears, or the user rectifies the error condition and presses the printer power button to resume printing:
Printer not connected at print time.
Printer not powered on at print time.
Printer powered off during a print operation via printer power button.
Printer powered off during a print operation via power source.
Printer cable disconnected during a print operation.
Cover open at start of print operation.
User lifts cover during a print operation.
Missing ink cartridge. Test both cartridges for two-pen products, and make sure that the correct pen is reported as missing.
Canceling print jobs. Make sure resources are cleaned up and the user can start a new print job without problems, etc. (Testing should include canceling a job both before and after printing begins. For printers that have an on-printer cancel button, this should also be tested both before and after printing begins.)
Out of paper. Test condition where printer is out of paper before print job starts and where printer runs out of paper during multi-page print job.
Paper jam in mechanism. Simulate by using banner paper, (taping four sheets of 8.5" X 11" paper together works as well) and printing a multi-page document.
Photo tray detected for printers that support it.
Print quality testing ensures that the driver is producing appropriate printed output. Testing should include at least the following types of documents:
Satisfactory output printing of text documents, mixed text & graphics documents, and graphics documents.
Both single and multi-page documents.
Satisfactory output printing in the different modes - grayscale, normal and photo.
No artifacts should be present in the printed output. Artifacts may include:
Clipping
Missing lines, graphics
Unexpected objects
Significant color shifts from original document source
Performance testing ensures that the driver is delivering the printed output in an acceptable time. Hewlett-Packard has provided HTML documents for the Performance tests, which can also be used for Final Validation testing. Performance tests should be run with a non-debug driver. If there is a significant deviation in print times from the average time provided in the following table, developers are strongly recommended to generate a script file as described in the Final Validation section and send it to Hewlett-Packard for analysis. (See Final Validation for emailing instructions.)
The following table gives the name of each file and the average time it should take to print on each printer series. Times are measured from the moment the print process is initiated until the paper drops into the output tray.
File Name
|
600 Series
|
800 Series
|
900 Series
|
File Size |
text.html |
tbd |
tbd | tbd | 9KB |
textgraphics.html |
tbd |
tbd | tbd | tbd |
biztest.jpg |
tbd |
tbd | tbd | 560KB |
hikey.jpg |
tbd |
tbd | tbd | 1.48MB |
imagetest.jpg |
tbd |
tbd | tbd | 1.69MB |
The Final Validation testing step verifies the final printer driver product by using a document set that exercises different parts of the CALLING code (browser, formatting, etc.). For final validation testing, developers should utilize the same HTML test documents used in Performance Testing, and should run the tests with a debug driver.
The SDK code has code built into it for Final Validation testing and script generation. Instrumented so that when a debug flag (build define “CAPTURE”) is set, all API calls along with their data are recorded in what is called a script. From this script, a large class of problems can be found that would otherwise potentially take a very long time to debug.
Hewlett-Packard strongly encourages developers to email the printer driver output (script files) back to Hewlett-Packard for print quality review and recommendations based on the results; this service is offered at no charge. Hewlett-Packard can then work with the developer to identify print quality issues and correct them.
In an effort to control costs associated with this program, Hewlett-Packard may not be able to test or debug every script file submitted for review. (Hewlett`-Packard charges no fees for the SDK or associated costs such as script file review, in an effort to keep this product available to as many developers and platforms as possible.) Developers are still strongly encouraged to submit their script files, and Hewlett-Packard will make every effort to review them. Developers will be notified within five (5) business days as to whether or not Hewlett-Packard will be able to review and return their script files.
To submit the script files, log on to the SPP website (http://www.hp-developer-solutions.com/) using your assigned login name and password, and send an email titled "Script Files", with the attached script files. Be sure to include your name, email and phone number in the email, should Hewlett-Packard need to make direct contact. Hewlett-Packard may verify the correctness of the printing sequence, paying particular attention to the following:
Valid API calls
Correctness of the calling sequence
Any significant print quality issues
Artifacts
Output correctness
The first step in producing a script is to decide on the mechanism for storing it, and the format to be used. The easiest way to produce a script is to write the data to a file on local storage using standard “fopen/fwrite” commands. If such storage is available, the code included in the SDK will be sufficient. The data can be written in either binary or ASCII form; the binary form will produce smaller files and run faster.
Hewlett-Packard has encountered some systems where a storage disk is not available and the only means of capturing data is to use printf commands that are sent to a terminal window. In this case the base-class scripting code has to be overridden (in the derivative SystemServices class); the code can be copied as is from the base-class routines, replacing every file-writing call (fwrite, fputc, etc.) with a display call (printf), and avoiding the fopen/fclose calls in the methods OpenDebugStreamR and CloseDebugStreamR.
In order to capture the data from the terminal window, the ASCII format must be used (and in fact this is why we have provided the ASCII option). Thus the code that needs to be overridden is in the AsciiScripter subclass of Scripter, found in the file script.cpp. The second step needed is for the calling code to invoke the SystemServices methods InitScript and EndScript. InitScript, as usual, should be called after the SystemServices object is constructed and before any other API calls are made. InitScript takes two parameters: the name of the script file to be created on disk (ignored in the diskless implementation), and a flag that is TRUE if ASCII format is to be used. EndScript should be called after everything else has finished and been cleaned up, except of course for destruction of the SystemServices object. Both these calls should be conditionally compiled into the calling code, so that they only occur in debug builds (see next paragraph).
The final step is to compile all the code with the symbol CAPTURE defined, and with the files in the “debug” subdirectory included in the build. Note that CAPTURE should not be defined in any production builds, as performance will be severely degraded. Run the test print-job and send the resulting file (one per job – managing the files as you see fit through passing in different filenames, or copying the result to a different filename after each run,) to Hewlett-Packard via the email instructions in the Final Validation section.