Product Development

Inside Whitepaper

• Introduction
• Need For APDK
• Objectives of APDK
• Overview of APDK
• Developers Implementation
• Parallel 1284 versus USB
• Bi-directional versus Uni-Directional
• Sample of Calling Code
• How to make the driver
• Printers and Features Supported
• Miscellaneous Features Supported
• Limitations
• Printing Support in Palm
• Printing Indirectly via a Desktop
• Why Print from the Palm?
• What can be printed from the Palm?
• Implementation of Indirect Method of Printing
• An Overview of Conduits
• An Overview of HotSync Manager
• Printing Directly to a Printer
• Conclusion
• References

• Home »
• Whitepapers »
• Printing Solution for Mobile printing on HP printers

Printing Solution for Mobile printing on HP printers

Introduction

The Personal Digital Assistant or PDA was introduced to replace the bulky paper organizers that people have long carried around. The PDA is a tiny, fully functional computer that you can hold in one hand. PDAs can even hold your downloaded e-mail and play music. The only feature lacking is facility to Print.

HP has enabled such embedded devices to have printing functionality by releasing an SDK called the Appliance Printing Development (APDK). Using the APDK, developers can write their own device drivers for the HP DeskJet series of printers, targeting their host system. Thus, non-PC devices such as palmtops, web TV terminals, watches, digital cameras, cell phones, and handheld PCs can make use of HP printers.

APDK contains a minimum set of codes, but is not a complete driver - it serves as the basis for creating a very small yet functional printer driver. To extract a complete device driver, a developer has to code for some functionality in the targeted platform.

This document will discuss about the APDK, Palm Printing functionalities, and the issues in creating a printer driver for the Palm using APDK.

Need For APDK

Before the APDK technology was introduced, non- PC devices had to connect to the Printer through a PC. For example, in a Digital Camera, the digital content had to be transferred to a PC in order to take printouts. Now, non-pc devices can connect to HP DeskJet printers directly without the help of a PC, due to the introduction of the HP APDK.

Objectives of APDK

Overview of APDK

The APDK final product is designed to accept pre-formatted, 24-bits RGB raster data and/or ASCII text, convert it to a high-quality, printer-ready data stream, and send it to an HP printer via a host-implemented I/O mechanism. The SDK also helps to provide the necessary structure and controls for a given print job, and enables the system (through an API) to perform various printer maintenance activities, (e.g. cleaning the printer pens).

The SDK is primarily responsible for converting device-independent data into a device-dependent, printer-optimized stream of bytes. Because the conversion process for color inkjet printers is quite complicated, it is important to not change device-independent portions of the SDK code.

If the target platform doesn't have a pre-existing printing functionality, then the user has to put in extra effort on the application software on the target platform to support printing. He must then write the printer driver for that platform

The following diagram clearly gives the flow when printing using APDK

Developers Implementation

To run the driver, four public classes are used (not all classes are used for each driver). There is one global function, used to determine the properties of the current version, and one auxiliary object used only for debugging purpose.

Classes

Auxiliary Objects

Global Function

Abstract Class "System Services" To Be Implemented By Host System Interface.

System Services is an abstract base class that requires implementation of various routines by the host environment in order to compile.

InitDeviceComm: InitDeviceComm is a method included in the base class whose function is to ensure that communication can be established with the printer, and the printer can be identified. InitDeviceComm must be called from the derivative SystemServices constructor.

DisplayPrinterStatus: DisplayPrinterStatus is a method implemented in the derivative class that allows communication of the driver status (errors, conditions requiring user intervention, etc.,) to user interfaces provided by the host.

ReadDeviceID: ReadDeviceID is a method implemented in the derivative class for retrieving the raw DeviceID string from the printer. ReadDeviceID is dependent on the type of communications protocol used, (1284, USB, or other methods.) If access to the printer's DeviceID is not possible due to I/O issues on the host system, have this function return BAD_DEVICE_ID to allow proper operation of the printer driver's error handling system.

SystemServices - This object encapsulates functionality that must be supplied by the host system, including memory management and I/O, clock access, user notification, etc. The abstract base class must be instantiated in a host-specific derived class, where the system code is hooked up to the required driver entry points. The only reference to this object in API-calling code should be to its constructor and destructor, which must be invoked prior to and after all other driver calls.

SystemServices is an abstract base class; the developer has to derive a class from Systemservices, and in that class every method in System Services has to be implemented.

Let ProtoServices be a class derived from System Services. The implementation of the methods is shown in the following.

// Include necessary header files ProtoServices:: ProtoServices(char* OutputFile):SystemServices() { // Get a handle to the port hport = openport(OutputFile) // Handle the error // Specify the I/O method if(IOMethod =="USB") IOMode.bUSB=TRUE // Establish a connection to printer constructor_error = InitDeviceComm() // Handle the error // Parse device id devid - an array of 256 characters err= GetDeviceID(devid,256,TRUE) // Handle the error The device id is a large string comprises manufacturer name,device name etc. Parse that string get the model name. } // End of constructor // To close the opened port ProtoServices::~ProtoServices() { ClosePort(); } // ProtoRegistry is a derived class of abstract base class Device registry // Dummy implementation of derived class constructor ProtoRegistry::ProtoRegistry(): DeviceRegistry() {} // Getting the appropriate printer instance DRIVER_ERROR ProtoRegistry:: InstantiatePrinter(Printer*&p,SystemServices *pSS) { // Get an instance for the appropriate printer p=new ProtoDeskJet660((ProtoServices*)pSS); } // Printer class instance for DJ6xx printer ProtoDeskJet660:: ProtoDeskJet660(ProtoServices* pSS): DeskJet660(pSS,TRUE) {} // Function needed in Uni-directional cable, Explicitly select the printer with //model ID DRIVER_ERROR ProtoRegistry:: SelectDevice(const PRINTER_TYPE printerModel) { DeviceRegistry::SelectDevice(printerModel) // Assign the return value to a printer type } // Implementation of ProtoServices functions voidJob -This object receives processes and transmits data to be printed by one device on successive pages. The PrintContext and Job together form the core of the driver. ProtoServices:: DisplayPrinterStatus (DISPLAY_STATUS ePrinterStatus) { //status - pointer to a character array //Check the ePrinterStatus with predefined Printer statuses and return to //user. // For example if(ePrinterStatus==DISPLAY_OUT_OF_PAPER) status="out of paper" } // HP API functions call internally to get the Device model ID DRIVER_ERROR ProtoServices:: ReadDeviceID(BYTE * pBuffer, int iSize) { DRIVER_ERROR err; int iDevIDLength = iSize; // Get the raw device ID string from the printer err = GetDevID(pBuffer, &iDevIDLength); pBuffer[iDevIDLength] = '\0'; } // Reads the printer returned information's DRIVER_ERROR ProtoServices:: FromDevice(char* pReadBuff, WORD* wReadCount) { return (ReadPort(pReadBuff, wReadCount)); }

PrintContext -This object serves two purposes. First, it encapsulates knowledge about all devices supported in available driver components. It can be queried at runtime to determine the capabilities of the attached device. Second, it allows for setting optional parameters of a print job, such as media size and margins, use of color and data-resolution, etc.

Job -This object receives processes and transmits data to be printed by one device on successive pages. The PrintContext and Job together form the core of the driver.

Font- This object is used to control printer fonts when sending ASCII data. (Printer fonts are beneficial in cases where the system lacks a reasonable font engine, or other cases.)

Parallel 1284 versus USB

If USB will be the print solution I/O method, the printer driver must be informed by setting the flag IOMode.bUSB to TRUE in the constructor of the derivative SystemServices class. The drivers produced by the Hewlett-Packard Print Driver SDK require this information due to I/O and error handling differences between USB and parallel /1284 connectivity.

Bi-directional versus Uni-Directional

Hewlett-Packard strongly recommends using bi-directional communication (bi-di) instead of uni-directional communication (uni-di) when implementing print solutions with this SDK. Bi-directional communication provides complete communication between the user and the printer, and enables plug and play capability, which provides seamless identification and use of Hewlett-Packard DeskJet printers without any input from the user.

If a uni-directional I/O method is the only option, the driver can still be used although the user will not have the advantage of the printer-to-host system communication for troubleshooting. In this situation, the host system will need to prompt the user to report the model they will be printing to before initiating a print job. The hosting system is responsible for storing this printer model to prevent further prompting from the user again.

In normal bi-directional communication, Initdevicecomm tries to establish contact with the printer when the SystemServices class is created. If successful, the model number is saved for later use. When the PrintContext is created, the pointer for the SystemServices class will be used to check if the model number has been previously saved. If it was, bi-directional communication has been achieved.

Sample of Calling Code

This is the code that acts as an interface between the Host System and HP Internal codes.

A Sample code that gets Text as an input and send the Text to HP API Functions.

/////////////////////// To print Text ///////////////////////////// DRIVER_ERROR printtext(char* text,PRINTER_TYPE pt, int Printmode,char*outputfile,PAPER_SIZE ps) { // Create an instance for protoservice which is derived from systemservices class Protoservices *psys =new Protoservices();// 1 // Check for constructor error DRIVER_ERROR err=psys->constructor_error;//2 if(err > NO_ERROR) return err; // error if(err< NO_ERROR) // prompt to user - warning // Create an instance of printcontext class PrintContext *ppc= new PrintContext(psys); // 3 // Check uni-directional case or bi-directional case if(! ppc->PrinterSelected()) ppc->SelectDevice(pt) // uni-directional case else // no implementation, since bi-directional case automatically selects device // Create an instance of job Job *pjob=new Job(ppc); // 4 if(Printmode >= ppc->Getmodecount()) // 5 // Set the max count to printmode otherwise use the same printmode Printmode = ppc->Getmodecount()-1 // Setting the printmode ppc->SelectPrintMode(Printmode) // Setup fonts for sending ascii data ppc->PrinterFontsAvailable(Printmode)// 6 // Font object settings Font *pfont // 7 pfont-> RealizeFont(fontindex,fontsize,fontcolor,boldflag, italicsflag,underlineflag) // Send the text to printer with other settings // 8 pjob->TextOut(stringpointer,stringlength,fontobject, horizontal position,vertical position) // Caller has the responsibility to deallocate all the instances specifically font //object }

Steps involved in the Process

///////////// To Print a Image///////////////// DRIVER_ERROR PrintImage(unsigned int NumPages, unsigned int PageHeight, // 1 unsigned int PageWidth, // 2 BYTE JobArray[NumPages][PageHeight][PageWidth*3] ) // 3 { // Step 1 to 4 in text printing has to be repeated // JOB LOOP for (int i=0; i < NumPages; i++) { // PAGE LOOP for (int j=0; j < PageHeight; j++) { err = pJob->SendRasters( JobArray[i][j] ) // 4 } // deallocate all the instances err=pJob->NewPage() // 5 }

Steps involved in the Process

Recording a Script

Developers can utilize the script recording device in order to communicate with Hewlett-Packard when debugging, problem solving, or quality testing.

How to make the driver

Minimum Host System Requirement

Hardware

Software

C ++ compiler, linker and standard libraries supporting string and other functions and platform specific libraries.

CPU Bandwidth

CPU Bandwidth needs depend on the type of printing support required as well as what other operations are occurring in the system at print time.

For graphics support:

A 100 MHz Pentium class processor.

For simple, ASCII-only text support:

A low-end processor.

Available Memory

Code & static tables (50 - 120K).

Run-time buffer space (25 - 60K, possibly 120K for high-res 6 color).

To build the driver

A Skeletal Makefile is needed to compile the core source files or any IDE.

Printers and Features Supported

The following features are supported by the APDK and apply to all printer families and family members:

Printer family derivatives are available on the market and should be considered to have similar feature functionality as other members of their family type. (8xx Series Only - The scope of this Series does NOT include the older 850C, 855C, 870C or 890C printers.)

The following HP Deskjet printers have been included in the printers supported by HP APDK 3.0

The following Hewlett-Packard DeskJet printers are not supported by this SDK:

Any non-Hewlett-Packard printers, or Hewlett-Packard non-DeskJet printers (including OfficeJet LaserJet and PhotoSmart printers) are also not supported by this SDK.

Print Quality

The quality of printed output can vary widely in the thin-client environment, due to host limitations. Some factors that can affect quality are:

To justify the Print Quality of the APDK driver, let us take a sample of the original image and the scanned image of the output of the APDK driver for the same.

Print Modes

The Print Mode is based on the resolution and no of inks used. The number of print modes for each printer type is given by the GetModeCount function in PrintContext. Typically, there is a default color mode and a grayscale mode; other modes with special properties such as high-resolution photo quality are available for certain printer models. In some cases, the developer must choose between features such as device-based text and photo quality. This is accomplished by selecting the mode (Print Context member SelectPrintMode,) and then querying with PrinterFontsAvailable. Every mode has a string identifier (for potential use in a user interface) given by GetModeName.

When bi-directional communication with the printer is available, the PrintContext constructor selects a default mode based on the installed pen. (The default mode is the "lowest" or fastest mode still compatible with the pen.) In order to override this setting, (possibly due to selected user preferences or unavailable bi-directional communication,) the SelectPrintMode method is provided in PrintContext.

SelectPrintMode takes a zero-based index. By convention, index 0 always refers to the Grayscale mode GRAYMODE_INDEX=0). Index 1 DEFAULTMODE_INDEX refers to the "normal" color mode; other values up to refer to specialized modes. If the selected Print Mode parameter requested is incompatible with the installed pen, SelectPrintMode returns a WARNING. Because it is a warning and not an error, it is possible to proceed using the requested mode even under the incompatible conditions. Examples of incompatibilities include using GRAYMODE when the pen has colored ink. The results are a gray-looking output that was wastefully produced by combining colored inks. Another incompatibility, using DEFAULT MODE when a "photo-pen" is installed, results in "normal" pen output quality instead of an output the more expensive photo-pen was intended to deliver. Some incompatibilities may even result in no useful output whatsoever. SelectPrintMode(int) has been deprecated in the APDK 3.0. The New Method is S electPrintMode(QUALITY_MODE, MEDIATYPE, COLORMODE, BOOL);

New methods added in APDK 3.0 :

Use PRINTMODE_VALUES *GetPrintModeSetting() to determine the quality, mediatype, colormode, and device text settings for the current print mode.

DRIVER_ERROR SetPenSet(PEN_TYPE ePen) allows the caller to specify the pen set in the printer in uni-di mode.

Resolution

Effective graphical output resolution depends on the PrintMode selected for the attached Printer model. In this SDK, two resolutions can be selected: 300 d.p.i. (dots per inch,) or 600 d.p.i., (the latter being used only for various "Photo/Best" modes.) To determine the acceptable resolution for the currently selected printer and mode, call the PrintContext function, EffectiveResolution. Remember that the calls must be in the appropriate order, or the results will not be valid. For example, if SelectDevice and/or SelectPrintMode are called after EffectiveResolution, the result of the EffectiveResolution call will no longer be valid.

Miscellaneous Features Supported

Apart from printing, APDK supports many other features.

PhotoTray Selection

If a printer, like the DJ 9xx series, has a PhotoTray support used for printing, the user can select the option of PhotoTray installed so that output can be extracted in the PhotoSize Paper.

Cleaning the Print Cartridges

If the APDK driver produces a grimy output, it may be due to a cartridge problem. To clean the Print Cartridges, the user needn't go to the service center. APDK provides a API Function called PerformPrinterFunction to clean the Print Cartridges. The developer can make use of the API to provide the end user with this option.

Debugging a Driver With Scripts

The APDK has been instrumented so that when a debug flag (build define "CAPTURE" is set, all API calls along with their data are recorded in what Hewlett-Packard calls a script. From this script, a large class of problems can be immediately found that would otherwise take a very long time to debug.

HP's Support to know the printer driver quality

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.

To submit the script files, log on to the SPP website (http://www.hp-developer-solutions.com) using the user assigned login name and password, and send an email titled "Script Files", with the attached script files. Be sure to include user 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

Limitations

Printing Support in Palm

Until recently, Palm-Sized devices did not support the printing functionality. This means that the developer has to put in additional effort to bring printing functionality in Palm. There are two ways printing can be done in palm-sized devices. They are

Printing Indirectly via a Desktop

If users don't have a serial or USB port printer or don't want to purchase a cable, they can "print" by transferring data to the desktop computer. This computer must run some sort of terminal emulation software, like ClarisWorks (Mac or Windows) or HyperTerminal (Windows 95/98/2000). Users can transfer the data through any techniques available and save the output to a file that a particular printer can understand on the desktop, to be printed later if required. For example, *.pcl is a file recognized by HP Printers. Alternatively, users can set the terminal emulation software to a "transfer" mode where it just transfers the incoming information directly to a printer. Therefore, although it is an inelegant solution, users can actually print to any printer connected to the desktop without any special cabling whatsoever.

Why Print from the Palm?

The necessity may arise in a number of cases. For example, the user's job may involve visiting customers in the field, or working at trade shows, and he may need to print out an order or a receipt on a portable printer. The user may also be a doctor doing rounds in a hospital, a delivery truck driver, a field service representative, or one of the many other mobile workers in today's workforce. The printing feature may also be useful for users who work in the office but use software on the Palm device that has no desktop counterpart.

What can be printed from the Palm?

Users can print information from the built-in Palm databases - memos, schedules, address book information, to-do lists, expenses, emails (from both the Palm Mail and iMessenger applications) and clipboard contents. Users can also print from any applications that enable the printing functionality.

Implementation of Indirect Method of Printing

Printing indirectly via a desktop pc from the palm is implemented as follows:

When the user presses the print option in the palm application, the data to be printed is stored in a palm database. The HotSync Application, which is a Desktop Application, is used to connect the desktop and handheld. It starts synchronizing the palm and desktop by running the Conduit that is registered to it. The Conduit is responsible for the transfer of data from the handheld to desktop and vice-versa. HotSync is an application that runs in the desktop, which monitors the serial port for communication between the conduit and the handheld. A conduit is a plug-in module for the HotSync®Manager application, which transfers data between a Palm Powered Thandheld and a desktop computer.

When a user puts a Palm OS device in its cradle and presses the HotSync button, the handheld application begins communicating with the desktop conduit. Then the data is written to a .pcl (Printer Control language) file that a HP Printer can recognize. The .pcl file is given to the HP DeskJet printer for printing through HP APDK driver for windows.

The Flow of operations when synchronizing data between palm and PC.

An Overview of Conduits

A conduit is a plug-in module for the HotSync®Manager application, which transfers data between a Palm Powered Thandheld and a desktop computer. The HotSync Manager runs the conduits that have been installed on the user's desktop computer when the user places a handheld into the cradle and presses the HotSync button. Conduits are typically designed to synchronize or back up data from a specific handheld application database. You can develop conduits with any of the suites that make up the Conduit Development Kit (CDK) for Windows from Palm.

Development System Requirements

To develop conduits with the C/C++ Sync Suite, your development system must be equipped with the following:

Implementation of function that reads palm database and writes to a file

int WriteToFile(CSyncProperties &sync) { // Open the remote database with conduit API, note the name of the database should //exist in the palm err= SyncOpenDB(printDBName, 0, rHandle, eDbRead | eDbShowSecret )) // Open a file stream to write the data // Get the record count of the database so that records can be read from max to min err = SyncGetDBRecordCount(rHandle, recordCount) // CrecordInfo is a structure maintained by the conduit to format the raw record //from the palm CRawRecordInfo recordInfo; recordInfo.m_FileHandle = rHandle; // handle to the database recordInfo.m_RecIndex = recordCount-1; recordInfo.m_TotalBytes = (unsigned short) sizeof(gBigBuffer); recordInfo.m_pBytes = (unsigned char *) gBigBuffer; recordInfo.m_dwReserved = 0; recordInfo.m_TotalBytes = 300; recordInfo.m_pBytes = (unsigned char *) gBigBuffer; //Get the record from the database using the API err = SyncReadRecordByIndex(recordInfo) // Write the data to file }

An Overview of HotSync Manager

HotSync is an application running in the desktop that gets activated when the hotsync button in the handheld is pressed. It starts synchronizing the palm and desktop by running the conduit that is registered to it. It also does some backup operations.

What Happens When a Synchronization Occurs

Registering and Unregistering Manually Using CondCfg

CondCfg is an application that uses the Conduit Manager. This application displays all the registered conduits and allows you to register conduits, change registered information, and delete conduits.

Required conduit entries

The following entries are required to register a conduit:

Conduit

The name of the conduit DLL. If this entry doesn't include a directory, the name must be found in the HotSync directory or current PATH; otherwise, it should include the full pathname to the DLL. (Generally, you keep your DLLs in the HotSync directory.) If your conduit is written using Java, this entry should be "JSync.DLL", a C++ shim that translates between C++ and Java.

Creator

The four-character creator ID of the database(s) your conduit is responsible for. Your conduit will be called during a HotSync only if an application with this creator ID exists on the handheld.

Directory

In the HotSync directory, each user has a subdirectory. Within each user's directory, each conduit has its own directory where it can store files. This string specifies the conduit's directory name.

Optional entries

The optional entries are more numerous. They include the following:

File

A string specifying a file (if the string doesn't include a directory, it is assumed to be within the conduit's directory). This is intended to be the local file that the conduit will sync the handheld against. However, your conduit is not restricted to using only this file (some conduits may need to read/write multiple files on the desktop).

Information

A string that provides information about your conduit. This string can be used to resolve conflicts. If more than one conduit wants to handle the same creator ID, an installation tool could display this string and ask the user which conduit should be used for syncing.

Name

A string that is the user-visible name of the conduit.

Priority

A value between 0 and 4, this controls the relative order in which conduits run. Conduits registered with a lower priority run before conduits registered with higher priorities. If you don't set this value, the HotSync Manger uses a default value of 2 for your application.

Remote DB

A string specifying a database name on the handheld. This string is provided for you to use in your conduit when it runs; your conduit isn't required to use it, however.

Username

The name of the user for which this conduit is installed. Note that this entry is not currently used.

Printing Directly to a Printer

This section gives a brief idea of how printing directly to a printer from palm can be done.

"Launch Code" is an important term in palm applications. Launch codes are a means of communication between the Palm OS and the application (or between two applications). An Application launches when it receives a launch code.

The printer driver for the palm is an application which launches when it receives a predefined launch code named sysAppLaunchCmdExgReceiveData that notifies the driver that it should receive incoming data (can be character or byte stream) from some other application.

Palm Applications that need printing functionality can send the launch code to the driver and use its functionality by invoking the system manager function called SysAppLaunch. Thus the driver gets activated and sends the stream of data to the printer using the API functions TextOut if text to be printed or SendRasters if image to be printed. There is no additional effort for the developer to represent the data in PrinterControl Language(PCL), Since HP's internal code does this. This way printing functionality can be achieved in palm.

However, printing directly from palm through APDK might need some converters due to the following issues.

I/O Port Conflicts between Palm and APDK

The printer driver depends on the underlying Operating System (OS) to provide basic access to whatever I/O port is connected to the printer.

Any non-Hewlett-Packard printers, or Hewlett-Packard non-DeskJet printers (including OfficeJet, LaserJet and PhotoSmart printers) are also not supported by this SDK.

Among Deskjet Printers, only the following printers are supported by this SDK.

The commonality among these printers is that they don't accept serial data. Only Parallel or USB port is supported in these printers. From the above construct it's clear that APDK doesn't send serial data to printers.

Conflicting to this, In Palm Current communication protocols are:

Palm Connectivity Issues

Infrared.Infrared printers are not supported by APDK. There are several devices on the market, which are "IR-to-parallel" adapters, which essentially convert any printer into an IrDA printer. This is the perfect solution for the office environment, where you have one printer serving multiple Palm users. Just attach one of these to your printer, and every one of them can print using this IR to the printer, while at the same time the pass-through port allows the existing parallel connection to continue.

Parallel.Most current LaserJet and InkJet printers have a parallel input using a standard Centronix connector; some, especially smaller portable printers, have unique, miniturized, parallel connectors. Palm devices have only serial output and IrDA. To do this you need a "serial-to-parallel" converter. This is not to be confused with a simple cable. You can find parallel cables with a 25-pin connector that looks like (indeed, physically it is) a serial connector on one end and a Centronix connector on the other. If it sells for less than $20, it is not a serial-to-parallel converter but rather a simple parallel cable. Serial to parallel converters sells for more like $50-$100.

NOTE: Printers with bi-directional parallel ports, including the HP720C, are not compatible with serial-to-parallel printer cables.

USB.Many newer Palm handhelds and many newer HP printers have a USB input. Generally it is not possible to print to a USB printer from a palm without a special USB hub-like device in-between, since both these deices are slaves.

Conclusion

HP has paved the way for the embedded devices to have printing functionality through its APDK. In some cases, due to the issues mentioned above, we may need some sort of converters or infrared sensors while developing the driver for palm. Thus, the Palm has an additional feature. HP APDK can be used to develop printer driver for almost every embedded device.

References

 

Copyright © 2010 Calsoft Labs Incorporated

• Terms Of Use
• Privacy policy
• Sitemap