Skip to content

Script Plug-in

A plug-in that transform a flat xml data stream into a collection of printer control language scripts (eg: ZPL,EPL ).

Report Plug-in Layout

Layout properties

The required layout properties for the Script plug-in:

Name Value
layout-type SCRIPT
plugin-class ifs.application.reportingservices.impl.extendedformatter.csvplugin.ScriptPlugin
output-method {BINARY,FILE,E-MAIL}
output-extension <Any>
flattened-xml:enabled TRUE
flattened-xml:strongtyping TRUE

Plug-in properties

Name Type Description
mode {script,xml} Script mode or XML mode
repeat {on,off} on - Create scripts for all the rows in the XML.
off - Create one script for the first xml row only
repeaters {Block type} NULL (nothing) - Will generate scripts for all the data rows in the xml.
{Block type} - Will generate scripts for only the mentioned block type. Example <repeaters>BARCODE_LINE</repeaters>
file-name <any> used only with the XML mode. specify the stored layout name

Plug-in data

The Printer Control Language script is written inside the <data> tag of the rpl. The expected format is:

    <![CDATA[PCL Script]]>  

A PCL Script can contain variables. Variables in the form of "[@<variable-name>]" and will be replaced by the scalar values in the runtime

^FO50,100^FD"Bar Code, Bar None"^FS  

Plug-in variables

Contains the variables used inside the script.

<variable name="variable-name">tns:-Xpath-to-the-variable</variable>



Variable description
<variable-name> can be any unique string
<tns:-Xpath-to-the-variable> should be selected using the Report Designer Function editor. load the desired report schema that you are building the script against, select a data node, the corresponding tns path will appear the the lower level. copy and paste tns path in the RPL variable.

The X-Path can also be written without the "tns:" prefixes.


When creating you own layout for the scipt plug-in it might be easiest to start from the following template and just fill in the special configuration needed is your particular case.

<?xml version="1.0" encoding="UTF-8"?> <report-layout>    <properties>       <version>8.0</version>       <layout-type>SCRIPT</layout-type> <!--SCRIPT,XSL,XML,EXCEL-->       <plugin-class>ifs.application.reportingservices.impl.extendedformatter.scriptplugin.ScriptPlugin</plugin-class>       <output-method>BINARY</output-method> <!-- BINARY,FILE,E-MAIL-->       <output-extension>txt</output-extension>          <default-output-reference>          <binary></binary> <!-- leave empty to control this from the print dialog (it will be the physical printer connected to a logical printer) -->          <file></file> <!-- not used unless changing output-method above to FILE-->       </default-output-reference>       <full-xml>TRUE</full-xml>       <flattened-xml>          <enabled>TRUE</enabled>          <strongtyping>TRUE</strongtyping>       </flattened-xml>       <report-id>TRANSPORT_PACKAGE_LABEL_REP</report-id> <!-- Change this to your REPORT ID -->       <report-title>Zebra Label</report-title> <!-- Title shown in the drop down, if installed via the installer -->    </properties>    <plugin>       <properties>          <mode>script</mode> <!--script,xml-->          <repeat>on</repeat> <!--on,off-->          <repeaters></repeaters> <!-- null = all rowtypes-->          <file-name>zebra.zpl</file-name>        </properties>       <data>          <![CDATA[[@ZPL_SCRIPT]]]> <!-- This can be a static script or completely dynamic (all ZPL generated in the RDF) as in this case.-->       </data>       <variables>          <variable name="ZPL_SCRIPT">tns:TRANSPORT_PACKAGE_LABEL_REP/tns:TRANSPORT_PACKAGE_LABELS/tns:TRANSPORT_PACKAGE_LABEL/tns:ZPL_SCRIPT</variable> <!-- this is what a variable looks like-->       </variables>    </plugin> </report-layout>  
### Label Printer Emulator ###   Sometimes you will not have a physical label printer available when designing and testing your printer control script solution. However, a label printer is essentially just a socket listener that listens for a printer control script to be sent. We have a small socket listener tool that can mimic this behavior and just write the communication in a log file. You can use this tool to verify the configuration all the way up to the actual print out. If this would be useful for you, the tool can be found [here]( You need Java to run it.