Class Identifier WFS_SERVICE_CLASS_PTR = 1

This specification describes the functions provided by a Printer and Scanning (PTR) service.
The XFS printer service defines and supports five types of banking printers through a common
interface:
• Receipt Printer
The receipt printer is used to print cut sheet documents. It may or may not require insert or eject
operations, and often includes an operator identification device, e.g. Teller A and Teller B lights, for
shared operation.
• Journal Printer
The journal is a continuous form device used to record a hardcopy audit trail of transactions, and for
certain report printing requirements.
• Passbook Printer
The passbook device is physically and functionally the most complex printer. The XFS definition
supports automatic positioning of the book, as well as read/write capability for an optional
integrated
magnetic stripe. The implementation also manages the book geometry - i.e. the margins and
centerfolds -
presenting the simplest possible application interface while delivering the full range of
functionality.
Some passbook devices also support the dispensing of new passbooks from up to four passbook
paper
sources (upper, aux, aux2, lower). Some passbook devices may also be able to place a full passbook
in a
parking station, print the new passbook and return both to the customer. Passbooks can only be
dispensed
or moved from the parking station if there is no other media in the print position or in the entry/exit
slot.

f an XFS form or media file is UNICODE encoded then, consistent with the UNICODE standard
[Ref. 2], the file
must start with a Unicode Byte Order Mark (BOM) and the UTF-16 encoded data that follows must
be in the byte
order indicated by the BOM. The two-byte BOM prefix in a text file indicates a Little Endian
(0xFFFE) or Big
Endian (0xFEFF) notation. On a Windows operating system the byte order encoding is Little
Endian.
If command parameter data is UNICODE encoded then this data will be UTF-16 encoded and the
byte order must
be Little Endian. UNICODE command parameter will not start with a BOM

he specification defines a standard set of interfaces in order to provide multi-vendor

interoperability: if an
application uses the API to communicate successfully with a Service Provider, it should work with
another
conformant Service Provider of the same type, developed by another vendor, without any changes.
To work with
more than one hardware implementation of a device, an application must retrieve the device
capability information
- this will allow the application to successfully interact with different variants of the same hardware
device.
Applications that use the vendor specific fields of XFS commands may not be able to interact
successfully with
another vendor’s conformant Service Provider. Applications should isolate vendor specific access to
devices in
order to maximize consistent device control across multiple device Service Provider
implementations. Any Service
Provider that conforms to the SPI definition can work with a range of conformant applications.
As new versions of the XFS device classes are developed and released, changes to the device class
interface
specifications are inevitable. Application exposure to these changes is controlled via the version
negotiation process
described later in this specification. Applications need to be updated to support new releases of
XFS, but to
minimize the migration effort it is recommended that they should be developed in such a way that
they can handle
additional error codes and new output literal values being added to existing commands within future
versions of
XFS in a graceful manner. In addition, applications must release the memory for all events received,
this includes
events that the application may be unaware at development time,