This document contains information proprietary to Zebra Technologies Corporation.
This document and the information contained within is Copyrighted by Zebra
Technologies Corporation and may not be duplicated in full or in part by any person
without written approval from Zebra.
While every effort has been made to keep the information contained within current
and accurate as of the date of publication, no guarantee is given that the document
is error-free or that it is accurate with regard to any specication. Zebra Technologies
Corporation reserves the right to make changes, for the purpose of product
improvement, at any time.
Trademarks
Zebra is a registered trademark and Virtual PrintWare is a trademark of Zebra
Technologies Corporation. Windows is a registered trademark of Microsoft
Corporation in the United States and other countries. All other trademarks or
registered trademarks are marks of their respective holders.
Close a TCP/IP Connection ........................................................................................................... 37
Worldwide Support ....................................................................................................... 39
ii PrintManager Programmer's Reference Manual P1057447-002
Purpose
1
Introduction
The purpose of this manual is to dene and describe the PrintManager application
programming interface (API). The PrintManager API supports two methodologies for
interfacing to an application: Message-based printing and SDK-based printing; both
methods require communication via TCP/IP or via drag-and-drop from a hot-drop
folder.
PrintManager is a service that runs on Microsoft Windows operating systems.
PrintManager can process ZMotif-based and message-based jobs—this includes
template- and job-based which both support XML and CSV. PrintManager creates
print jobs from the received data, directing the jobs to the appropriate printers.
PrintManager supports the ZXP Series 3, ZXP Series 7, and ZXP Series 8 Card
Printers.
PrintManager stores templates and images to be used for template-based printing.
Templates are XML documents, and images are binary data which may be one of
many formats including bitmap and jpeg. The variable data for a template-based print
job is packaged as a data document in XML or CSV le format. The ZMotif SDK is
used to build print jobs from templates, image les, and data documents.
PrintManager can also receive ZMotif-based jobs directly. The ZMotif SDK can be
used to build and send a print job to PrintManager.
ZMotif Job
XML Doc
Data Document
CSV Doc
Print Manager
PrintManager consists of three modules: Queue, Store, and Job. Queue Modules
are virtual printers that receive data streams, parse the data, and send the data
to the Store Module. The Store Module saves the data for future processing. The
Job Module gets data via the Store Module, analyzes the data, creates print jobs,
determines the appropriate printer, and tracks job status.
PrintManager Data consists of job-specic data received by PrintManager for
purposes of performing template- and job-based printing using the message interface
described in this manual. The job-specic data must be formatted as a document
using the XML or CSV le formats. The data document is delivered to PrintManager
via TCP/IP from any host capable of streaming data documents via TCP/IP such as
Linux, UNIX, and Microsoft Windows
The XML document shown below is an example of an XML-formatted data document
used for a template-based print job.
Print Job Processing refers to the tasks required to complete a print job. The tasks
associated with the completion of a print job include receiving data documents when
template-based job messaging is in use, receiving job xml les when job-based
messaging is in use, and receiving ZMotif-based jobs when the ZMotif SDK is in use.
Template-Based Printing is a process that combines a template document and its
required images (if appropriate) with a data document to create a ZMotif-based print
job.
PrintManager uses the ZMotif SDK to build a print job from a template, its required
image(s), and a data document.
Template documents specify the card layout by dening the required parameters.
These parameters include combinations of the following elements: font types, the
number of sides to print (single or double), graphics, text, barcode, lines, rectangles,
ellipses, and magnetic encoding (if supported). Some of these parameters become
placeholders for data—the data document contains the data required by these
placeholders.
Before a template and its required image(s) can be used by PrintManager to
build a ZMotif-based print job, the template and image(s) must be stored where
PrintManager can locate them. The template interface specication includes
commands which enable templates and images to be programmatically stored by
PrintManager.
Introduction
Template-Based Printing
ZMotif is a print job language that contains job characteristics and binary images.
Software tools for Microsoft Windows developers that generate ZMotif are the ZXP
Series printer drivers, and ZMotif Software Developer Kits (SDKs).
Data documents specify data to be bound with a template at job creation—they can
be XML or CSV formatted documents.
The following XML document is an example of an xml-formatted data document used
by the sample template on the previous page; its contents would be merged with the
sample template’s contents to create a print job.
XML Data Document
<data template=”text_job”>
(template to be used with the data)
<logo>zebra_logo</ logo >
(data for print job)
<Firstname>John</ Firstname >
(data for print job)
<Lastname>Doe</ Lastname >
(data for print job)
</data>
The following CSV document is an example of a CSV-formatted data document used
by the sample template on the previous page; its contents would be merged with the
sample template’s contents to create a print job.
CSV Data Document
template,logo,Firstname,Lastnametext_job,zebra_logo,John,Doe
CSV Data Docuement Items (not part of the CSV document)
Template, placeholder in template
logo, placeholder in template
Firstname, place holder in template
Lastname placeholder in template
text_job, template to be used with the data
SDK-based printing is a process that makes use of Zebra’s ZMotif SDKs for building
print jobs and sending them to PrintManager.
An application would use various methods in the SDK to build a print job. Once built,
the job is then sent to PrintManager by making use of other methods available in the
SDK. Unlike template-based printing, SDK-based printing delivers pre-built jobs to
the PrintManager; therefore, it is not required to build the job. Instead, PrintManager
simply forwards the job to an appropriate printer.
This chapter describes the methods for interfacing an application to PrintManager:
template-based printing and SDK-based. The chapter focuses on ZXP Card Interface
which is the message-based specication for template-based jobs; it also provides
an introduction to the SKD-based approach.
2
Template-based printing makes use of template documents and data documents
to build print jobs. A template document describes a card’s layout by dening fonts,
sides, graphics, text, barcodes, QR codes, lines, rectangles, ellipses and magnetic
encoding. The template also species data and image binding. A data document
denes the information unique to a card such as a customer’s name, an employee’s
identication number, and date of expiration.
SDK-based printing makes use of the ZMotif Printer and Graphics SDKs to build print
jobs. Using the SDK approach, each job is built through the use of methods provided
by the SDK as if all aspects of the job were unique, even if common background
images, titles, etc are part of each card produced.
The ZXP Card interface provides a standardized process for sending and receiving
data to/from the PrintManager. Data documents can be comma-separated values
(CSV), XML documents or binary data. Data is sent within an interface command
payload; the payload can be: templates, images, job data, or functional commands.
Responses will be XML formatted documents or binary data.
There are four ZXP Card interface commands supported by PrintManager: Store,
Submit, Delete and Request. The Store command downloads templates and images
on the PrintManager. The Delete command removes templates and images from
the PrintManager. The Submit command sends data or functional commands to be
processed by the PrintManager. The request command is used to request specic
information from PrintManager including job status, list of available queues, and a
card_thicknessthickness of card in mm; default is 30
delete“no” = job data will be kept until the next job is received; (default)
destination“eject” = normal exit path for printer without laminator (default)
“yes” = job will be deleted at the end of processing
“reject” = card goes into the reject tray
“hold” = card goes to the home position
“feeder” = card returns to the input location
“lam_top” = card goes to laminator for top side lamination
“lam_bottom” = card goes to laminator for bottom side lamination
“lam_both” = card goes to laminator for top and bottom side lamination
“lam_any” = card goes to laminator without regard for laminate
availability. It will be laminated top, bottom, both or neither (if no
laminate is installed, the card simply passes through the laminator)
“lam_none” = card passes through laminator without lamination
A job document is used to provide all required information to create a specic print
job. Unlike a data document for a template-based job, a job document does not
reference a template. Instead, it includes the information that would be contained in
both the data and template documents to dene a job; thus, it uses many of the same
xml tag descriptors to dene a print job. This section identies all of the possible
The start of the data section of each data document is dened by the beginning data
tag. Within the data tag the name of the template to be used is identied.
The eld information represents the data that is unique to each card. It can consist
of text, image, and barcode data. The eld name must appear within opening and
closing xml tags while the data for the eld must appear between the tags as shown
This section demonstrates how to build a data document using the CSV le format.
Header
Each data document requires a header to identify the start of the document.
string dataDoc = “template”;
Start of Data Section
The start of the data section of each data document is dened by a comma ‘,’.
docData += “,”;
Field Name Information
The eld information represents the data that is unique to each card. It can consist
of text, image, and barcode data. The rst eld name must appear immediately
following the comma identifying the start of the data section. Each subsequent eld
name must be preceded by a comma. The last eld name must be terminated with a
carriage return-line eld.
The data for the rst eld must appear immediately after the carriage return-line feed
of the eld name information. Each subsequent data eld must be preceded by a
comma. Unlike the name elds, the last data eld does not require a carriage return-
ZXP Card interface provides a standardized process for sending and receiving
data to/from the PrintManager. Data can be comma-separated values (CSV), XML
documents or binary data. Data is sent in an interface command payload consisting
of templates, images, job data or functional commands to the PrintManager.
Responses returned from PrintManager will consist of XML formatted documents or
binary data.
There are four interface commands supported by PrintManager: Store, Submit,
Delete and Request. The Store command downloads templates and images to the
PrintManager. The Delete command removes templates and images previously
stored on the . The Submit command sends data or functional commands to the
PrintManager. The Request command requests information from the PrintManager.
The interface commands are built and sent to the PrintManager through the use of a
data document using the xml format described in the data document section of this
manual.
ZXP Card Interface Command Syntax
The syntax for the interface commands is as follows:
zxpf:command:sub-command:name:size:type:payload;
zxpf = header for the command
command = operation to be performed: store, delete, submit, or request
sub-command = the category the command will act upon: template, image, job,
data, or information
name = name of the data being stored, deleted, submitted, or requested
The following elds are optional based upon the command and sub-command:
size = size of the payload in bytes being stored or submitted
type = format of the payload: xml, bmp, jpeg, gif, png
payload = ACII text, or byte array of data: template, data document, job
document, or image
Each eld of the command is delimited by a ‘:’ character.
Response if the submit commands above succeed: (job id is returned)
<?xml version=”1.0” encoding=”utf-8”?>
<zxpf_resp>
<job_ids>
<job_id>15</job_id> <=Job Number returned for data or job document submitted
</job_ids>
</zxpf_resp>
Example of a response if the submit commands above fail:
<?xml version=”1.0” encoding=”utf-8”?>
<zxpf_resp>
<error_code>1002</error_code>
<detail> Unable to read data from the transport connection: A connection attempt
failed because the connected party did not properly respond after a
period of time, or established connection failed because connected host
has failed to respond.
</ detail>
</zxpf_resp>
Request Command
The Request command requests information from the PrintManager.
Example of a response if the request command above fail:
<?xml version=”1.0” encoding=”utf-8”?>
<zxpf_resp>
<error_code>1002</error_code>
<detail> Unable to read data from the transport connection: A connection attempt
failed because the connected party did not properly respond after a
period of time, or established connection failed because connected host
has failed to respond.
</detail>
</zxpf_resp>
Request job status from PrintManager: request information on pending
All documents, template, job, and data, are delivered to PrintManager in the
same manner: using TCP/IP. The process of sending documents to PrintManager
involves: opening a TCP/IP connection between the host PC and the PC running
PrintManager, sending the documents via this TCP/IP connection, receiving a
response from PrintManager, parsing the response to determine whether or not
the document was successfully delivered to PrintManager, and closing the TCP/IP
connection.
Note • Data documents are sent to PrintManager in the same manner regardless of
their format: XML or CSV.
This section demonstrates how to send a document to PrintManager from a host PC
running Windows and how to parse PrintManager’s response to determine whether
or not the document was delivered successfully. The sample code demonstrated in
this section is written in the C# language; however, it is not a requirement to use C#.
Open a TCP/IP Connection
Declare the required variables, instantiate the required objects and open the
TCP/IP connection. Note: error handling and other programming code has been
intentionally omitted.
Socket s = null;
IPAddress address = null;
string ipAddress = “10.1.24.29”;
int port = 9100;
IPAddress.TryParse(ipAddr, out address);
IPEndPoint endpoint = new IPEndPoint(address, port);
s = new Socket(endpoint.AddressFamily, SocketType.Stream, ProtocolType.Tcp);\
//open connection:
s.Connect(endpoint);
Send a Document
Declare the required variables, and send the document to PrintManager. The sample
code depicted here builds upon the sample code shown in the previous section.
Note: Error handling and other programming code has been intentionally omitted.
Declare the required variables, and receive PrintManager’s response.
The sample code depicted here builds upon the sample code shown in the previous
sections. Note: error handling and other programming code has been intentionally
omitted.
int bytesRead = 0;
// Response data buffer, sized to read rst four bytes (payloadSize)
byte[] respBuffer = new byte[4];
// Offset into respBuffer
int offset = 0;
// Number of bytes to read
int bytesToRead = respBuffer.Length;
// Read rst four bytes to determine payload length
do
{
bytesRead = s.Receive(respBuffer, offset, bytesToRead, SocketFlags.None);
if (bytesRead > 0)
{
offset += bytesRead; // Increment offset into respBuffer
bytesToRead -= bytesToRead; // Subtract number of bytes remaining
}
} while (bytesToRead > 0);
// Convert four byte response to payload length
int payloadSize = BitConverter.ToInt32(respBuffer, 0);
// Clear and resize respBuffer to payloadSize
Array.Clear(respBuffer, 0, respBuffer.Length);
Array.Resize(ref respBuffer, payloadSize);
// Read the rest of the response data (payloadSize)
do
{
bytesRead = s.Receive(respBuffer, offset, bytesToRead, SocketFlags.None);
if (bytesRead > 0)
{
offset += bytesRead; // Increment offset into respBuffer
bytesToRead -= bytesRead; // Subtract number of bytes remaining
}
} while (bytesToRead > 0);
Declare the required variables, and receive PrintManager’s response.
The sample code depicted here builds upon the sample code shown in the previous
sections. Note: error handling and other programming code has been intentionally
omitted.
To determine whether or not the document was received correctly, check for an
error condition. In the case of a data document or job document, a check of the
response for a jobID can also be made. The presence of a job id conrms that the
data document or job document has been submitted to a printer as a print job to be
processed.
The sample code below demonstrates how to determine if a data document or job
document was delivered successfully.
Close the TCP/IP connection and release the allocated memory. The sample code
depicted here builds upon the sample code shown in the previous sections. Note:
error handling and other programming code has been intentionally omitted.
Sending ZMotif-based jobs to PrintManager involves the use of the ZMotif SDK to
build the job, open a TCP/IP connection between the host PC and the PC running
PrintManager, build the job, send the job via this TCP/IP connection, receive
PrintManager’s response, and close the TCP/IP connection.
Unlike template-based printing, the response from PrintManager does not require
parsing to determine if a job was successfully delivered. Instead, the response will
include a job id if delivered. In the case of a failure, the SDK will throw an exception
identifying the cause of the failure. Another difference between template-based
printing and ZMotif-based printing is that the ZMotif SDK requires the host PC to be
running a version of the Windows operating system.
This section demonstrates how to send a ZMotif-based job to PrintManager using the
SDK and how to determine whether or not the job was delivered successfully.
Note: The sample code demonstrated in this section is written in the C# language;
however, it is not a requirement to use C#.
The programming code demonstrated here is a basic, high-level view of the ZMotif
SDK. Please consult the ZMotif Programmers Reference Manual for details.
Complete, sample applications, written in several programming languages, are
available upon request from Zebra’s SDK support team at Card_SDK_Questions@
zebra.com.
Open a TCP/IP Connection
Declare the required variables, instantiate the required objects, and open the
TCP/IP connection. Note: Error handling and other programming code has been
intentionally omitted.
string ipAddress = “10.1.24.29”;
int port = 9100;
Job job = new Job();
if (!job.IsOpen)
{
ipAddress += “:”;
Building a job includes dening the side of the card to be printed on, whether or not
the printing is to be color or monochrome, and the type of information to be printed
on the card. The sample code below demonstrates how a job would be built to print
a bitmap image on the front-side of a card, and builds upon the sample code shown
in the previous section. Note: Error handling and other programming code has been
intentionally omitted.
Sending a job requires dening how many copies of the card should be printed and
retrieving a job id from PrintManager. The sample code below demonstrates how to
send a job to PrintManager, and builds upon the sample code shown in the previous
sections.
Note: If an invalid job is built using the SDK, the SDK will throw an exception upon
trying to send the job to PrintManager. Error handling and other programming code
has been intentionally omitted.
int copies = 1;
int jobID = 0;
job.PrintGraphicsLayers(copies, out jobID);
Receive PrintManager’s Response
Receiving PrintManager’s response is nothing more than checking the jobID
returned to conrm a non-zero value has been received. The sample code below
demonstrates conrming PrintManager returned a non-zero job id, and builds upon
the sample code shown in the previous sections.
if (jobID > 0) //valid job id returned: job delivered to PrintManager successfully
{
//take appropriate action for valid job
}
else //invalid job id returned: failed to deliver job to PrintManager
{
//take appropriate action for invalid job
}
catch (Exception e)
{
//job built & delivered to PrintManager was invalid
//examine exception to determine the problem with job
}
PrintManager Programming Interface
Sending ZMotif-Based Jobs to PrintManager
Close a TCP/IP Connection
Close the TCP/IP connection and release the allocated memory. The sample code
depicted here builds upon the sample code shown in the previous sections. Note:
error handling and other programming code has been intentionally omitted.
job.Close();
do
{
Thread.Sleep(10);
} while (Marshal.FinalReleaseComObject(job) > 0);
Before returning any equipment to Zebra Technologies Corporation for in-warranty
or out-of-warranty repair, contact Repair Services for a Repair Order (RO) number.
Mark the RO number clearly on the outside of the box. Ship the equipment, freight
prepaid, to the address listed below:
Zebra Technologies Repair Services
333 Corporate Woods Parkway
Vernon Hills, IL 60061
webform: www.zebra.com/repair
T: +1 877 ASK ZEBRA (877 275 9327)
E: repair@zebra.com
Before returning any equipment to Zebra Technologies Corporation for in-warranty
or out-of-warranty repair, contact your supplier for a Return Materials Authorization
(RMA) number, or contact one ot the following repair centers for support and
instructions:
120 Robinson Road
#06-01 Parakou Building
Singapore 068913
T: +65 6858 0722
F: +65 6885 0838
E: tsasiapacic@zebra.com
Asia Pacic - Repair Services
Before returning any equipment to Zebra Technologies Corporation for in-warranty or
out-of warranty repair, contact Repair Services for a Return Materials Authorization
(RMA) number. Repack the equipment in the original packing material, and mark the
RMA number clearly on the outside. Ship the equipment, freight prepaid, to either
address listed below:
Zebra Technologies Asia Pacic Pte. Ltd.
No.5 Changi North Way Level 3
Singapore 498771
Agility Building
T: +65 6546 2670 ext 3203 and 3204
F: +65 6546 5328
E: APACRepair@zebra.com