RFID Label printing

RFID: Radio frequency identification A method of identifying unique items using radio waves. Typically, a reader communicates with a tag, which holds digital information in a microchip. But there are chipless forms of RFID tags that use material to reflect back a portion of the radio waves beamed at them.

Form Authoring

XFA has the capability to handle barcodes since beginning. In Adobe LiveCycle ES1.0, we introduced the support for elementary RFIDs also. It is  handle like any other barcode and named it rfid. The form author can put an rfid object on the label while designing label using Adobe LiveCycle Designer.

RFID set up in Adobe LiveCycle Output

To enable the rfid capability in Adobe LiveCycle Output service, first, the user needs to do rfid set-up based on the target rfid printer. The user has to configure the RFID parameters in the XDC file using Adobe LiveCycle XDC Editor, based on his rfid printer configuration before printing his first rfid label.
There are four device options in the XDC that one needs to configure.


It controls the number of times the printer attempts to write to a particular block of a single RFID tag. The accepted values for this option is between 0 to 10.
If the user doesn’t specify in its XDC, the printer will take the default value ’0′.


The number of labels that will be attempted in case of encode/write failure. This number is different from the rfidBlockRetries. The accepted values for this option is between 0 to 10.
If the user doesn’t specify in its XDC, the printer will take the default value ’3′.


It controls the encoding type of the data in the RFID label. The RFID readers should have same tag type as the rfid printer has. The accepted values for this option varies printer to printer. Consult your printer manual for this. Generally this option takes values between 0 to 5.

value tag type
0 None
1 EPC Class 0
2 EPC Class 0 Plus
3 EPC Class 1 64-bit
4 EPC Class 1 96-bit
5 ISO 18000-06B

These tag types also has some frequency standards. In some countries, some of the frequencies are restricted and in that case the rfid printer might not support those corresponding tag types. In that case the printer will use the default tag type. There are number of other EPC and ISO standards.


This is the distance of the microchip on the label from the top. The user needs to pass this value in dots. The accepted values are between 0 to length of the label.
If the microchip is located at the beginning of the label, the user needs to simply set this option to 0.


This is the setting which will be specified based on the fact whether the data used is HEX or ASCII.


Here you go. Once the above set-up is taken care of, you can generate the labels using the generatePrintedOutput API of AdobeOutputService. You can upload the edited XDC file in the Adobe LiveCycle Repository and pass its uri as XDC URI in the API.


A quick disclaimer here that RFID capability is supported only for Zebra labels (zpl) and not in PS/PCL or pdf documents generated by Adobe LiveCycle Output.


Adobe LiveCycle Central Migration Bridge

Adobe Output Central is a very old product with substantial customer base. Its design was basically watch folder based and it uses very naive string matching to run the customer workflows. The workflow steps can be simple command line invocations of the components of Adobe Output Central or any other executable. The core Adobe Output Central components are:

  1. JFMerge – it merges templates and data to generate formatted document (PDF/PCL)
  2. JFTrans – it converts structured text and overlay text to usable .DAT and XML data. It is also used for touching up existing data as ut contains a rudimentary scripting capability.
  3. XMLImport – it converts XML data to .DAT data.

Besides these Adobe Output Central has other helper utilities like send/read emails. The main goal of this document is to help central clients to move from the rudimentary hosting environment of Adobe Output Central to modern environment of Adobe LiveCycle. Adobe LiveCycle Output Service does similar things as Adobe Output Central. But it uses different data and template models which are xml schema based.

The pricipal problem with current clients moving to or looking to move to Adobe LiveCycle is the time required to transition. It is in the magnitude of 1-2 years. There are basically two things the customers need to do. They have to migrate their Adobe Output Central templates to Adobe LiveCycle Output templates i.e. XFA templates and migrate their Adobe Output Central workflows to Adobe LiveCycle workflows. Though Adobe LiveCycle Designer provides capability to import any Adobe Output Central templates and convert it back to Adobe LiveCycle templates, this proves to be a more time taking than migrating the workflows. In fact, migrating Adobe Output Central workflows to Adobe LiveCycle workflows is very easy with the hosts of services available with the Adobe LiveCycle suite. So if we could keep on using the Adobe Output Central from Adobe LiveCycle environment by migrating the Adobe Output Central workflows, that would give our customers freedom to migrate their Adobe Output Central templates to Adobe LiveCycle Templates at their own pace.

We have created Adobe LiveCycle Central Migration Brige in ES 2.0 that enables the user to call all aforementioned core executables of Adobe Output Central from inside Adobe LiveCycle environment. The other helper utilities of central are either lightly used or can readily be replaced by Adobe LiveCycle Foundation components. Adobe Output Central clients can build new processes using Adobe LiveCycle and over time move their Adobe Output Central based templates to Adobe LiveCycle templates at pace that suits them and their business needs; as well this allows for a small application to be transitioned independent of many others allowing for confidence in transitioning to be gained; rather than us pressing them to big-bang the transition.

Adobe LiveCycle Central Migration Brige exposes 3 different operations one each for each core component of Adobe Output Central. Each of the operation will simply fork the corresponding Adobe Output Central executable as a separate process with suitable commandline options. The Adobe LiveCycle CentralMigrationBridge APIs expose the most frequestly used commandline options as an input parameter to the operations. This component will use the existing Adobe Output Central installation from the same machine where Adobe LiveCycle is installed.

The general execution sequence from the APIs would be something like the following:

  1. Take input from the user and convert them into relevant command line options.
  2. Create a process using ProcessBuilder and pass all commandline options.
  3. The result would contain the output and several meta data files as well.
  4. Return the Result to the user so that he can pass them to the next step of the orchestration.

Besides the three core component of Adobe Output Central Adobe LiveCyle CentralMigrationBridge service will also provide a fourth operation, dataAccess to help customers convert their data models (.DAT file) into XML document that can be xpath’ed into. This will enable the user to process some of the options that is passed to the .DAT file. We’ll also provide a strongly typed client to the customer to help in their further development.

API Description

Signature for the operations of this DSC would be the following:

  1. CentralResult centralDataMerge(Document inTemplateDoc, Document inDataDoc, Document inoutPreambleDoc, String printerDestination, String inIniFilePath, String inAllOtherOptions) throws CentralMigrationBridgeException, DSCException
  2. CentralResult centralTransformation(Document inDataDoc, Document inDataModelDoc, String inIniFilePath, String inAllOtherOptions) throws CentralMigrationBridgeException, DSCException
  3. CentralResult centralXMLImport(Document inDataDoc, String inXCIFilePath, String inAllOtherOptions)throws CentralMigrationBridgeException, DSCException
  4. CentralResult {
    Document logDoc; //log file
    Document responseDoc; //jetform.rsp file
    Document traceDoc; //trace document that can be passed to the API again as preamble (Applicable only for merge API)
    Document resultDoc; //formatted output doc (pdf/pcl) in case of merge API, transformed doc in case of trans API and imported .dat in case of xmlimport

  5. Document centralDataAccess(Document inDataDoc, int inMaxBytesToProcss) throws CentralMigrationBridgeException, DSCException

Error Handling

Adobe LiveCycle CentralMigrationBridge service would throw the following errors:

Error codes Description
ALC-CMB-001-001 If the install directory specified by the user is not a valid Output Central installation directory.
ALC-CMB-001-002 If the central executables has returned with an error code.
ALC-CMB-001-008 Unexpected exception while starting any of the central executable.
ALC-CMB-001-009 Unexpected exception while running any of the central executable.
ALC-CMB-001-010 Execution interrupted while running any of the central executable.

The user can get central logs from the Output Objects returned by the APIs and debug the errors. The complete detail of the error would be in the log document returned by the APIs and not in the LC server logs. LC server logs would contain just the top level exception.