A Case for Open Software Architecture and Multi-Platform

Here is a scary thought: at Eclipse Corporation we have been working with document generation and management software for more than a quarter century. We started out with a product called FormsPlus/400, which ran exclusively on IBM’s AS/400 systems, now known as IBM i. Today clients expect open software and they want to run it on the platform of their choice.

 FormsPlus/400’s architecture was pretty straightforward:

1. You designed the “background” (a simulation of pre-printed paper forms) using a Windows based form design tool, “Delrina Form Designer” (Delrina was acquired by Symantec in 1995) and “printed” it to a file, using an HP LaserJet print driver. This PCL formatted file was then uploaded to the AS/400.
2. On the AS/400 there was a “green screen” application which was used to select portions of a printer file (spool file) and associate these portions with a field name (i.e. Line 17, Position 5 – 34 is the customer name of an invoice)
3. On another “green screen” program, you defined where these selected portions of the spool file were to be placed, to match the “pre-printed” design from step 1.
4. Finally, another AS/400 program was triggered whenever a selected spool file was generated. This program extracted the defined portions from the printer file and placed them at the defined positions and merged this information together with the previously uploaded PCL form.

FormsPlus/400 was installed hundreds of times at companies of all sizes and industries, worldwide. In the late 1990s, the Canadian JetForm Corporation, then one of the leading global document software companies, acquired the intellectual property of the FormsPlus/400 product.

In the early 2000’s, JetForm decided to convert all FormsPlus/400 customers to their JetForm Central product. JetForm Central was available for IBM AS/400, Windows, Unix, AIX and Linux. It was extremely popular around the world, in fact, so successful that software giant Adobe Systems acquired JetForm in February 2002. After the acquisition, JetForm Central was renamed Adobe Central Output server and successfully marketed by Adobe through the 2010s. Adobe discontinued sales and support for the product on June 30, 2016.

So, why am I talking about this in the context of “A case of Open Software Architecture”? Let’s start with some “real life” stories on FormsPlus/400. As some of you will remember, there was a lot of concern in the late 1990s, that the existing software packages would not be able to handle the switch of date formats from 199x to 2000. As part of one of these “Y2K” efforts, one of our largest FormsPlus/400 customers hired us to make sure that their forms would keep working come January 1, 2000. We went on-site and catalogued all of their existing forms. During this effort, we found well over 100 forms where the background had the “19” for the year “hard-coded”, because the spool files that were used had the year only as two digits. Ok, no big deal, let’s fire up the Delrina Form Designer, change it to “20” and re-upload the form. Hmmmmh….. “We had all of our form designs on Jack’s (Name changed to protect the innocent – LOL) PC, which had a disk crash two years ago…”. As mentioned before, FormsPlus/400 stored the “pre-printed” form in PCL format on the AS/400. Luckily, although PCL is not necessarily an easy file format to read for humans, we were able to change the “19”s to “20”s using a text editor. So, although in software heaven for many years, I declare that FormsPlus/400 had a “Semi-Open Software Architecture”. What matters is that we were able to help the client through their “Y2K” form crisis and it took only about four hours to have all their forms Y2K ready.
In another “Y2K” case, we weren’t so lucky: This client had already converted all of the forms to JetForm Central. JetForm Central’s Form Designer was a very powerful WYSIWYG tool. Once the form design was to the user’s liking, the form had to be “compiled.” The original (non executable) form design was stored as an .ifd file. The compile step added information about the selected output type (PCL, PDF, PostScript etc.) and stored this (now executable) form as an .mdf file.

Different client, same problem: The PC with the .ifd files had “died” and, naturally, there was no current backup of the form design files. All we had were the “compiled” .mdf files. We opened one with a text editor, and this is what we saw:

The joy of encrypted, proprietary file formats. There was no way for us to update the “19”s to “20”s for this client by “fixing” the .mdf. The only solution we had was to get the most current .ifd from the backup, create an .mdf from this version, merge it and compare the result with the current production version, then use the Design tool, make the adjustments based on our visual comparison, recompile with “20”s instead of “19”s … and hope for the best that we hadn’t missed anything. Bottom line: It took about four weeks to reapply the lost changes and to make their forms Y2K ready.

Unfortunately, many other popular Form products use proprietary and (most of the time) encrypted file formats.

When Adobe knew that it was time to start thinking about an Adobe Central successor, they created the product LiveCycle Output and based it on the XFA architecture, which was originally “invented” by JetForm. This form’s software was one of the early adoptions for creating and storing form templates and data files in an open file format. Today, the overwhelming majority of enterprise customers will not even consider buying a product that uses proprietary or encrypted data and template files (not to mention customers want to run their business on the platform of their choice and may even switch platforms after they purchase business software or forms software).

In LiveCycle Output, the form definitions were stored as XML with a file extension of .xdp. Here is a sample of a field object:

         <field name=”CONTACT” y=”34.202mm” x=”5.287mm” w=”63.214mm” h=”6.191mm” access=”readOnly”>

           <ui>

               <textEdit>

                 <border presence=”hidden”>

                     <?templateDesigner StyleID aped0?></border>

                  <margin/>

               </textEdit>

           </ui>

           <font typeface=”Arial”/>

           <margin topInset=”1mm” bottomInset=”1mm” leftInset=”1mm” rightInset=”1mm”/>

           <para vAlign=”middle”/>

           <bind match=”dataRef” ref=”$.CONTACT”/>

           <calculate override=”error”/>

         </field>

It’s a beautiful thing. Everything is quite obvious. More importantly, there is no compile step. The merge engine reads the .xdp, gets the actual data from an XML data file and produces the desired type of output. LiveCycle Output is no longer marketed as a stand-alone application and core support will end 03/31/2018. It can now only be ordered as part of Adobe’s AEM 6.1 Forms package, whether you need all of it or not.

Another Document software solution that is strictly based on the concept of Open Software Architecture is DocOrigin, which is developed and maintained by the core team of JetForm Central developers. They were well aware that the concept of encrypted and proprietary files had to be a thing of the past. DocOrigin also stores the form templates as XML. Compared with LiveCycle’s .xdp files, DocOrigin’s .xatw files removed a lot of the mostly unnecessary “fluff” which the XFA architecture dictated. A field object in DocOrigin’s .xatw template looks like this:

   <field name=”SHPZIP2″ type=”text” dataType=”string” backgroundColor=”transparent” foregroundColor=”#000000″ visible=”none” shading=”none” singleLine=”yes” allowSplit=”no” global=”no” resizableWidth=”yes” resizableHeight=”no” maxHeight=”0.0 in” lineSpacing=”0.0 in” angle=”0″ justify=”left middle” caseShift=”none”>

     <boundingRect left=”6.801969 in” top=”0.448031 in” width=”1.456693 in” height=”0.354331 in”/>

     <margin left=”0.03937 in” right=”0.03937 in” top=”0.03937 in” bottom=”0.03937 in”/>

     <border visible=”no” color=”#000000″ thickness=”0.008333 in” lineStyle=”solid” edges=”all” radius=”0.0 in”/>

     <font typeface=”Arial” size=”10.000″ italic=”0″ bold=”0″/>

   </field>

This is human readable and understandable. You know exactly where this field will end up on a page, which font and font-size it uses etc.

Just as in LiveCycle, DocOrigin’s merge process reads the .xatw file directly and produces the desired type of output by merging it with a data XML file. The output from DocOrigin can be one or more of the following simultaneously; PCL, PS, PDF, PDF/UA, PDF/A, HTML, Adaptive HTML and delivers it as print or electronic files.

If you are in the market for a replacement of your obsolete or sunset Document Generation software, ask the software vendor for one of their form template files. Open it with a text editor and see if you can figure out what it means. If you can’t read it or if it doesn’t make any sense, you may want to find a different product. Don’t let yourself be held captive by proprietary and/or encrypted file formats.