Forms Management

Posted on March 5, 2013 by Raghavendra Pandey | Comments (0)

This is second post in my previous series of LiveCycle Mobile Forms. In this post, I will introduce utility tool called Forms Management that eases out forms deployment on live production systems.

The Forms Management streamlines the process of updating, managing, and retiring thousands of forms and the business users can manage forms without any help from IT support.

One can access Forms Management console through http://<server>:<port>/lc/fm. Here is how it looks like once you log in using super admin user.

fm

 

There is search control where one can search through the forms. Forms Management UI shows all  LiveCycle applications that contains forms. You can go and select one of the applications and browse into the forms. You can select the forms and preview it as pdf or html5. Here is how preview screen looks like:

 

FM_Preview

You can select a form and edit metadata corresponding to it and the metadata is searchable too.

LiveCycle Mobile Forms

Posted on March 5, 2013 by Raghavendra Pandey | Comments (8)

One of the many new offerings in LiveCycle ES4 is Mobile Forms that is ability to display and fill forms on mobile devices like iPad and other tablets. Mobile forms uses the already stable and widespread html5 as its rendering format so practically, any device that supports html5 can show LiveCycle forms. With the explosion of mobile devices, our existing customers were looking for this component to increase their reach and not only that, it would also enable many new use cases. Mobile Forms plays key role in customer’s workflow and enabling that workflow step on mobile device will further reduce the time taken to complete the process.

Mobile Forms generates html5 document for XFA forms. The API is RESTful, another change from the Document based LiveCycle service APIs as html is more suited for http requests. Html fragment for XFA form can be embedded into any html document.

“Web” and “online” are two closely associated terms, downright synonymous to many people. But with the advent of html5, now people are developing offline web apps. Mobile Forms, being an html5 document, can also be used to build offline forms.  So one can open the form even if she is not connected to company intranet or for that matter internet. Mobile Forms closely follow the html5 offline W3C spec for building offline-able forms. I’ll discuss this feature in detail in some other post. Let’s focus on html5 form render first.

As I mentioned Mobile Forms is a RESTful application and its render API has the following commonly used parameters to specify form and data:

Parameters Description
template This parameter takes the file name of the template.
contentRoot This parameter is for specifying the path where template and associated resources resides.
dataRef This parameter takes absolute path of the data file to be merged with the template. Please remember it takes absolute value of the data file path.
data This parameter takes UTF-8 encoded data bytes to be merged with the template.
submitUrl The url where the form data will be posted to.
debugDir Directory location on server machine where the debug intermediate files will be dumped. Do not use this parameter in production as it will slow down the rendering considerably. This parameter is for Adobe internal usage and can be changed in the future.
templateBytes This parameter takes UTF-8 encoded template bytes to be rendered. This is again Adobe internal API and can be changed in future.


As you can see, Forms Mobile render API is fairly simple and can be easily used. Out of the box, the render API is exposed on both GET and POST. The sample uri looks like the following:

http://<lcserver>:<port>/lc/content/xfaforms/profiles/default.html?contentRoot=c:/xdps&template=sampleForm.xdp

Hit the above URL in browser and see your XFA forms being rendered as html5 document. XFA forms can also have webservices or scripts that are to be run on server side. In that case, the rendered html doc contacts http://<lcserver>:<port>/lc/content/xfaforms/submission/default.html url so make sure you don’t block this url while hardening the system in order to smooth functioning of form.

 

In the next post I’ll cover how to quickly test the forms.

 

 

Mobile Form Configuration

Posted on March 1, 2013 by Raghavendra Pandey | Comments (0)

Caching in Mobile Forms or any solution for that matter, plays key role in the performance. On the other hand, cache takes finite space to store intermediate artifacts that means you trade memory for better performance. In Mobile Form solution, we have exposed different strategies of caching to fine tune this trade off. I’ll first describe all the levels and what do they mean and then how to change the levels.

Mobile Form has 3 different strategy of caching that can be controlled using the configuration.

Cache Strategy Description
None This cache strategy enforces the solution no to cache any artifact. This will, in practice, slow performance and high memory availability due to absense of cache.
Conservative This cache strategy dictates to cache only those intermediate artifacts that are generated before the render of the form like template containing inlined fragments and images.
Aggressive This cache strategy enforces the solution to cache almost everything that can be cached. This includes rendered html content besides all the artifacts from Conservative level. This should result in best performance but it will also consume more memory for storing all the cached artifacts.

Aggressive caching strategy means you will get O(1) or constant time performance in rendering a form as rendered content of the form is cached.

The following section describes how to change the caching strategy based on you requirement:

  1. Go to  http://[server]:[port]/lc/system/console/configMgr and look for “Forms Configuration” and click on it. You see a dialog like following:
  2. You can select Cache strategy using the drop down.

Besides Cache strategy, one can also configure total in memory cache size and the upper bound on the size of the individual artifacts to be cached. HTML Forms, as of now, only do in-memory caching using LRU strategy.

If you select ‘None’ cache strategy, the cache gets cleaned up.

All about embedding font in the document

Posted on June 24, 2011 by Raghavendra Pandey | Comments (0)

 

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>

 

 

Merging image data into a XFA template

Posted on May 12, 2011 by Raghavendra Pandey | Comments (1)

There are many cases when a user may need to specify the image contents via a data file. Let’s take a simple hypothetical example. Say you are a company that specializes in printing purchase order forms for a number of customers. The form is designed once and it’s the data merged into the form that dictates the final format. Part of the data loaded in could be the customers company’s logo.

The Data File

or an image, there are two ways to specify the content.

  • Link
<image xmlns:xfa="http://www.xfa.com/schema/xfa-data">
<FFGraphic1 xfa:contentType="image/jpeg" href="C:\Sample.jpg"></FFGraphic1>
</image>
  • Embedded
<image xmlns:xfa="http://www.xfa.com/schema/xfa-data">
<FFGraphic1 xfa:contentType="image/tiff" xfa:transferEncoding="base64">
SUkqAAgAAAASAP4ABAABAAAAAAAAAAABAwABAAAAqQAAAAEBAwABAAAAwgAAAAIBAwADAAAApAIA
AAMBAwABAAAAAQAAAAYBAwABAAAAAgAAAAoBAwABAAAAAQAAABEBBAAEAAAAQIMBABIBAwABAAAA
...
AMp6AADKegAA2A8AAPgCAADCfQAAjPgAAFZzAQA=
</FFGraphic1>
</image>

In both cases the contentType attribute MUST be specified. If not specified, it will default to ‘text/plain’ and likely result is that the image will not be rendered. During the merge process, the contentType of the data is overrides the contentType specified in the template in order to coerce the field to the data contentType.

Note the xfa: namespace prefix is required for the contentType and transferEncoding attributes.

The Template File

<?xml version="1.0" encoding="UTF-8"?>
<?xfa generator="FF99V40" APIVersion="4.0.4200.2002"?>
<xfa>
 <template>
	 ...
	 <field name="FFGraphic1" y="35.56mm" x="81.28mm" w="91.55mm" h="68.53mm" access="protected">
	  <value>
		<image/>
	  </value>
	  <ui>
		<defaultUi/>
	  </ui>
	 </field>
	 ...
 </template>
</xfa>

RFID Label printing

Posted on May 11, 2011 by Raghavendra Pandey | Comments (3)

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.

 

Adobe LiveCycle Central Migration Bridge

Posted on May 11, 2011 by Raghavendra Pandey | Comments (0)

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
    }

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

Support for unicode characters on Zebra Labels

Posted on April 26, 2011 by Raghavendra Pandey | Comments (0)

In ES2, Livecycle introduced support for arbitrary unicode characters in Zebra Labels. Prior to this only latin-I charset was supported. Though there was support for Asian encoding like GBK(Simplified Chinese), Shift-JIS (Japanese), BIG-5 (Traditional Chinese) and KSC-5601 (Korean) but generic unicode support was missing.

Another pain was LC didn’t allow any font that is not present on the printer, to be specified in the label. This combined with above became a real problem with the middle east customers. The problem with Zebra is one cannot embed fonts inside the document like Postscript as downloading fonts on the printer is awfully slow. So the only option we left with is to rasterize the text and represent it as an image in the generated label. This way, the form author can get what he sees on the screen in pdf or in designer. Even with this approach, we felt that there is considerable file size bloating even after compressing the images of the document. Since XTG was rasterizing all the text present in the font other than the printer, which was not necessary sometime. For example, if the text is specified in english in Arial font, the end user might want to substitute it with the font present on the printer. In fact this is what we used to do before this change.

An option in XDC file is used to map to a font which is to be rasterized. The general font mapping sequence that is allowed in XTG needs both from and to font and along with it one can specify which unicodeRange to target. But here, the form author might not know before hand what data is going to be merged with the form. For example, there can be multiple textfields in the form with different fonts specified. The data to be merged in the form may contain non-english characters for some of the textfield. If the end user wants to map the form font into printer font, she has to specify that many mapping in the config file. So to ease the effort on the end user side, we exposed this option in xdc file where one needs to specify only to font and unicodeRange. This is a shortcut to the existing font mapping sequence.

<xdp>
    <xdc>
       <deviceInfo>
          <option>

            ...

            <!-- ========================================== -->
            <!-- Raster Substitution Font                     -->
            <!-- ========================================== -->

            <rasterSubstitutionFont typeface="CG Triumvirate_Normal_Normal" unicodeRange="U+20-U+FF"/>
         </option>
     </deviceInfo>
   </xdc>
</xdp>

The above entry is shortcut to the following config option:

<fontInfo>
   <map from="FONT_TO_BE_RASTERED" to="CG Triumvirate_Normal_Normal" unicodeRange="U+20-U+FF"/>
</fontInfo>

Here the printer driver for Zebra printer in XTG determines which font is going to be rasterized and based on that map that font to the specified rasterSubstitutionFont present in the xdc file.

There can be multiple rasterSubstitutionFont in the XDC file for different unicodeRange just like the font substitution entry.

Create Bookmarks in XFA Forms

Posted on April 11, 2011 by Raghavendra Pandey | Comments (5)

There is a growing demand from our customers to extend the bookmark capability of pdf documents to XFA also. In LiveCycle Server ES3, we are introducing the support for authoring bookmarks in XFA Forms. It is also available in LiveCycle Server ES2.5 via a patch.  This post will show how one can author bookmark in an XFA form and also how the final pdf does look like.

Authoring

You can define bookmarks at any of the XFA containers like subform, field or area.

The XFA processor starts processing bookmarks based on the following markup definition, under any of the valid container
elements. You can also specify multiple bookmarks for the same container. However, since only one extras tag is allow under any container markup, one can always wrap multiple extras tags inside another extras tag. LiveCycle supports up to two level of nesting for extras tags.

<subform> <!-- Any container element like subform, field or area-->
	<extras name="bookmark">
		<text name="name">ANY_NAME</text>
		<text name="color">0,0,0|R,G,B</text>
		<text name="style">normal | italic | bold | bold-italic</text>
		<text name="action">gotoPage | setFocus | runScript</text>
		<text name="script">ANY_FORM_LEVEL_SCRIPT</text> <!-- Javascript only. No formcalc support -->
	<extras>
	...
</subform>

Here is the description for various mark up parameters (Table below).
parameter description
name The name of the bookmark that will appear in the bookmark pane. If it is not specified, the bookmark will not be generated.
color The color in which the bookmark name is rendered. The color parameter should be indicated in the RGB scheme. For example, to insert a bookmark in red color, this parameter should be specified as 255,0,0. The default value for the color parameter is 0,0,0 (black).
style The style in which the bookmark name is rendered. The default value of the style parameter is none. Other values can be bold, italic, or bold-italic.
action The action that is performed when the bookmark is clicked, Values that can be used for the action parameter are: 

  • gotoPage: This is the default value. Focus is shifted to the page where the parent subform starts.
  • setFocus: Can be used when the parent container is a field. Sets the parent field in focus.
  • runScript: Triggers JavaScripts to be run. (This value is ignored in PDF/A documents)
script Relevant, when the value of the action parameter is set to runScript. Supports only JavaScript, that contains script objects present in the document scope.

 

To author bookmarks in XFA forms:

1) You can use the attached Designer macro. The macro has been written for Designer versions ES2 or later. For more information, see the blog on Design macros.

2) Download the bookmark macro from collateral.

When you invoke the macro, a dialog box  (as shown above) is displayed. In the dialog box, specify all the bookmark  parameter values.

 

Document generation

Once a bookmark has been authored, generate the PDF document. The bookmarks generated are available in dynamic and static documents. Bookmarks are compatible with Reader 9.0 and 10.0. You can use bookmarks in any XFA version document.

The bookmark will be generated in the same hierarchy as it is defined in the XFA Form design.

<subform name="root">
    <extras name="bookmark">
		<text name="name">parent1</text>
    </extras>
	....
   <subform name="level1">
		<extras name="bookmark">
			<text name="name">child1</text>
		</extras>
		...

		<subform name="level2">
			<extras name="bookmark">
				<text name="name">grand1</text>
			</extras>
			...

		</subform>
	</subform>

   <subform name="level1">
		...
		<subform name="level2">
			<extras name="bookmark">
				<text name="name">grand2</text>
			</extras>
			...

		</subform>

    </subform>
</subform>

For example, for the above form design, the bookmarks will be generated in the following hierarchy:

bookmarkRoot
	parent1
		child1
			grand1
		grand2

 

Limitations

  1. To ensure compatibility with existing Reader versions, some capabilities are limited.
  2. For security reasons, a user can change the value of any bookmark element/parameter except action and script.
  3. For dynamic forms, you cannot make changes using the script – LiveCycle Server will always generate bookmarks based on what user has specified in the template. For example, assume that a form contains a select-one-subform type subformset, and the author has defined bookmarks for all the subforms of the subformset. In such a scenario, for dynamic PDF documents, LiveCycle Server will generate bookmarks for all subforms, and for static PDF documents, LiveCycle Server will generate one bookmark, depending on which subform gets selected based on user input.
  4. Bookmarks defined for XFA containers which form master page content are ignored
  5. Bookmarks specified on containers other than subform, area, field, and draw objects are not supported, and may result in unpredictable behavior.
  6. Bookmarks with value runScript for the action parameter/element are disabled, if the rendered PDF is archived.
  7. If an interactive form with bookmark is flattened using LiveCycle Output Service, it will not retain the bookmarks that somebody has inserted after the generation of PDF using Acrobat or Assembler.

 

 

 

 

 

 

 

 

 

 

 

Simplifying the Input tray set-up

Posted on April 8, 2011 by Raghavendra Pandey | Comments (6)

We have observed and also received feedbacks from the users (whoever dared to do it) that setting up input trays has been quite a complex task. After designing the form, one needs to add the medium names used in the form to the xdc file
This blog post aims at simplifying this task and also clarify the steps that one needs to follow in order to set-up the input trays.

Input tray selection.

Basically, the input tray set-up problem can be defined as selection of paper from different input trays of the printer while printing the document. Without loss of generality, let’s take up the case of selection of two different trays (T1 and T2) for a template which has two different master pages (M1 and M2) and the user wants to select paper from tray T1 for master page M1 and similarly for master page M2, the user wants to select paper from tray T2.
We can categorize this requirement into two main sub-categories based on the paper sizes used in the master page. Before going ahead, I should mention that master page is basically a logical page which serves as a template for a set of pages in the xdp. The designer user can specify the page properties like page size at the master page level.

M1 and M2 represent two different page sizes.

In this case,

  1. Make sure that the medium name used in M1 and M2 is present in the printer xdc file.
  2. Configure printer trays T1 and T2 for paper sizes of M1 and M2 respectively.

M1 and M2 represent same paper size.

This is a bit tricky case and one has to make a heck of changes in printer XDC file. The sequence of steps can be as following:

  1. Add the mediums present in M1 and M2 to printer xdc file. To do this one may need the following information.

medium name (copy from template), short edge size, long edge size and in case of PCL one also need to give pcl sequence for this medium.

Please note that one has copy the medium names from template as the designer shows different UI name for any medium. For example it shows “Letter Plain” for “letterPlain” medium.

  1. Specify the tray sequences for T1 and T2 to map it to corresponding mediums M1 and M2. Please note that one has to specify tray sequence for a tray every single time whenever one maps a medium to this tray. This is because the UI table representing xdc schema is not properly normalized.

Basic Idea

One would have realized that input tray set-up is not an easy task esp. for second category use cases. There are lot of duplicate information one asks from user that can be easily determined from previous values given in the xdc file. And also there is no sync between the UI strings shown by designer and XDC Editor.

Separate Medium and Input Tray tables

Currently the medium table allows one to add and modify both mediums and the input trays they are mapped to. This table will be separated into two tables for medium and input trays. By giving a separate table to input trays, redundancy in input tray data can be avoided and better visibility is given to the user into what input trays are available.

Add a separate mapping tale

The mapping information is currently embedding in the medium table. Once medium and input tray tables are separated, a mapping table can better manage the mapping of mediums to trays.

Changes in UI

  • The tab page ‘Medium and Trays’ will be split into two pages, ‘Trays’ and ‘Mediums’, in order of appearance.
  • ‘Trays’ page will have the Input, Output trays specifications and input-tray-medium mapping tables. User will mostly be dealing with ‘Trays’ page.
  • ‘Mediums’ page will only have a Medium table with buttons to add/modify/delete mediums. Mediums page will be the last page as user will add/delete mediums rarely.
  • Sample screenshots are shown below.

Input Trays table

The current input trays table is merged with the medium table and looks like as follows:

The new input tray table will not have any mention of medium, and will look like as follows:

Please note that ‘Tray type’ column will be shown only for Postscript.

printers.
All columns in the table have unique values individually. An input tray cannot share its tray name, number or type with another input tray.

Addition of a new tray

Addition of new input tray is separated from adding a new medium. The new dialog looks like:

Medium table

The current medium table is the same as the current input trays table, and shown above .
The new medium table will be moved to its own ‘Mediums’ page. A sample screenshot follows:

The ‘PCL Sequence’ column will be shown only for PCL printers.
The Stock name in Medium table will be unique. Rest of the columns may not have unique values.

Addition of new medium

The current ‘add new medium’ dialog mixes adding a new medium with adding a input tray and input-tray-medium mapping. It looks like as follows,

The new ‘Add new medium’ dialog looks like,

Input tray and medium mappings table

This is a new table proposed to be located in ‘Trays’ page.

Modification of a mapping after addition is not intuitive, so user will have to remove and then re-add a mapping to modify its medium or input tray.
The medium name column will have unique values.

Specify a new medium mapping

‘Map medium to tray’ is a new dialog.

The medium and input tray will be available as drop downs. Mediums already mapped to a tray will not be available.