Posts tagged "Adobe Output Service"

All about embedding font in the document

 

Some designers wish to include only a few specific fonts in a PDF to ensure all possible end-users have access to those fonts, especially if the fonts are uncommon. Some other designers wish to embed fonts, but exclude fonts that they know exist on their end-users’ systems.

Adobe LiveCycle Forms and Output both supports these kind of use cases. This blog posts demonstrates how to do that. There are two constructs in XCI (configuration packet of XDP) to support this alwaysEmbed and neverEmbed. The following examples show this.

Example 1: How to use alwaysEmbed

In this example, a form uses the fonts “FontIsRare”, “FontIsCommon”, “FontC”, and “FontD”. Given the following in the configuration:

</fontInfo>
    <embed>0</embed> <!- - embed is off - - >
    <alwaysEmbed>FontIsRare</alwaysEmbed>
    <neverEmbed>FontIsCommon</neverEmbed>
</fontInfo>
The output file is expected to have only "FontIsRare" embedded.

Example 2: How to use neverEmbed

In this example, a form uses the fonts “FontIsRare”, “FontIsCommon”, “FontC”, and “FontD”. Given the following in the configuration:

 

<fontInfo>
    <embed>1</embed> <!- - embed is on - - >
    <alwaysEmbed>FontIsRare</alwaysEmbed>
    <neverEmbed>FontIsCommon</neverEmbed>
</fontInfo>

The output file is expected to have “FontIsRare”, “FontC”, and “FontD” embedded. “FontIsCommon” is not embedded.

 

The fontInfo element may appear in the configuration file as a child of pdf, pcl, zpl, ps, and image. The elements alwaysEmbed and neverEmbed will only be meaningful under the pdf element and will not be meaningful for image, pcl, zpl, and ps, the reason being that there is no support for adding non-embedded fonts that are not recognized by the printer in pcl, zpl and ps.

alwaysEmbed is only honored if embed is set to ‘0’.  Here is how your full xci file look like:

<xfa xmlns:xfa="http://www.xfa.org/schema/xci/1.0/">
    <config xmlns="http://www.xfa.org/schema/xci/1.0/">
        <present desc='Presentation Agent'>
        <pdf> <!--  [0..n]  -->
            <fontInfo>
                <embed>0</embed>
                <alwaysEmbed>Wingdings</alwaysEmbed>
                <alwaysEmbed>Book Antiqua</alwaysEmbed>
                <alwaysEmbed/>
                <neverEmbed>Wingdings</neverEmbed>
                <neverEmbed>Book Antiqua</neverEmbed>
                <neverEmbed/>
            </fontInfo>
         </pdf>
        </present>
    </config>
</xfa>

 

 

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.

rfidBlockRetries

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’.

rfidLabelRetries

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’.

rfidTagType

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.

rfidTransponderPosition

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.

rfidDataType

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.