Javascript correctly hides fields on screen but not when printed

[KJSTech]

I'm using a product that pulls field data in from XML when processing PDF documents for a loan origination system.  I have some code that I am trying to use to hide a particular field when our loan origination system passes the value "$0.00".  I also have some code that I am trying to hide a date field next to a co-borrower 1 and co-borrower 2 fields.

When processing the PDF's through our system they look correct on screen.  If there isn't a co-borrower 1, there is not a date in the date field next to the name.  Same deal with co-borrower 2 and its date field.  When there is no loan insurance, the field is hidden.  When there is loan insurance, the amount is in the proper field (example $917.17).

However when we go to print the flattened PDF's when processing is completed, no matter what we see a value in the loan insurance field, even if it is $0.00.  Also we see the date next to each co-borrower's name.

Why doesn't the javascript code to hide a field work when printed?  Why is it only working when on screen?  This should be a simple fix.  Our product vendor wants to bill us to correct this.  Surely I am VERY close to fixing this without involving "professional support"?

The code is as follows

var LN_INS_OPT_PREM_AMT_P = this.getField ("LN_INS_OPT_PREM_AMT");
var C_NAME_P = this.getField ("C_NAME");
var CS1_NAME_P = this.getField ("CS1_NAME");

   if (LN_INS_OPT_PREM_AMT_P.value == "$0.00")

      {

        getField("LN_INS_OPT_PREM_AMT").display = display.hidden;

      }

    if (C_NAME_P.value == "")

      {

        getField("LN_EFFECTIVE_DT_D1").display = display.hidden;

      }

    if (CS1_NAME_P.value == "")

      {

        getField("LN_EFFECTIVE_DT_D2").display = display.hidden;

      }

Images:  When Processing note the fields are correctly hidden.

After processing when you go to print the flattened PDF's, the hidden fields are revealed.

[Bernd Alheit]

What happens when you fill and print the form?

[gkaiseril]

You are setting the display to visually hide the form field (display.hidded) not make it non=printable (display.noprint).

See the field object display property.

[try67]

The "hidden" value means the field is not visible on the screen, as well as when printed. This is explained in the page you linked to, actually...

[KJSTech]

Like try67 said, the object display should be hidden from both view AND print if set to hidden.

I mean I can try setting it to noPrint, but then it will be displayed...  I need it off for both.

Bernd Alheit,  The form fields are pre-filled by our loan processing application.  It passes the field data into our processing software via an XML file, in which our processing software takes this data and merges it with the PDFs we have.

The PDFs are actually created in Autonomy Forms Designer, which was a LiquidOffice product, but now owned by HP.  PDF JavaScript can be utilized so I'm trying to see how Adobe is parsing this javascript.

[Bernd Alheit]

What happens when you do it manually?

[KJSTech]

I can type anything I want in the loan insurance field.  Even if I type $0.00 and tab to the next field, it stays there.

If I type something in Co-Borrowers name, the date fields do not unlock.

Now this is Reader 11.0.19, maybe I need something newer to get anything to "run" manually. 

[Bernd Alheit]

Where did you placed the JavaScript code? Can you share the form?

[Test Screen Name]

My first instinct is that the JavaScript is ignored when printing. Is this happening only when SOMEONE ELSE prints it somehow (by a system perhaps not entirely described, but assumed to be Acrobat Reader)?  Or does it ALSO happen if you see the fields as expected on screen and then immediately print from Reader?

[KJSTech]

This happens immediately.  It looks perfect on screen but once you print it, the hidden fields are no longer hidden.

The javascript is at the end of the code which was written using Autonomy Forms Designer 7.5.2.  Its a Liquid Office Product, now owned by HP.

The third party software that does the processing and flattening of the documents is web based.  Our loan origination system pushes XML data to them via what I think is a SOAP call or something to that nature.  The third party software uses this information in the XML to determine which documents to pull in depending on what type of loan product it is.  Based on the XFM documents done in Autonomy Forms Designer (exported as Fill and Print PDFs), Javascript can be used to do all sorts of things, like group checkboxes, make things manditory, mask fields (like SSN for example), check things off if something else is filled out.... you name it.  If it can be done in Javascript it can be done. 

The third party software does the processing and the end users sees the form through Adobe Reader iview in Internet Explorer.  Adobe Reader is in a frame which is wrapped in this third party applications UI.  In the top is a continue or cancel session, so as you click continue it loads the next document and so forth, until all documents are reviewed and signed.  Signing can be done via Topaz signature pad, or it can be sent out via Adobe Echosign for electronic remote signature capture. 

Maybe I would need to share the form, but let me get authorization to do so, or maybe sanitize it for public internet consumption.  I can tell you the code in the file is what I pasted above, however there is a little more to it that checks (or doesn't check) boxes next to three different fields (dept protection/insurance, GAP insurance, MBP - Mechanical Breakdown Protection / Auto warranty program).

The function is called with no arguments and here is a screen shot of the full function..

[Test Screen Name]

Than you for the details but where is the printing in this process? what component or software prints?

[KJSTech]

The printing is after the documents are processed.  There is a small eye icon and when its clicked on, the PDF loads in a window that uses Adobe inside the frame in Internet Explorer.

During processing fields are not always locked, and they behave as one expects. Once you hit continue, the software loads the next form.  Once you complete all of the forms you are at the end where you can preview them to print.  What is printed is viewed by  QC and they can flag it to go into a document imaging system.  It's quite the elaborate process, and I'm trying to figure out what's at fault here. My code, Adobe, the vendors code, etc...  I'm coming here first because its standard JavaScript and its Adobe PDF... plus they want to charge.

I'll try to document the process in screen shots below...

In our system you generate documents.  This displays a list of all forms in a document set.  You hit process and a new window appears and you go through in order.  During this "processing" phase, on screen everything is executed perfectly.  Correct fields are hidden in this example circled in blue.  You would click the continue button to advance to the next form if there is one. 

When you are done processing all of your forms you would want to view them.  You can view them individually by clicking the grey eye icon I have cirled in red below.  Or the very bottom Document Set would merge all of them in order from top to bottom.  This is a very simple document set below.  Once the document signing is complete the people who signed may want a printed copy so you would click the eye and then once the PDF opens you would click print.  Also however it looks in this preview is how it will be sent over to document imaging system where it is properly indexed for future retrieval.

This is what you get when you do preview.  It prints exactly how it previews.  Note for some strange reason the circled fields are no longer hidden.  This is the problem I am trying to overcome using JavaScript. 

I hope it helps illustrate the flow.  I know this is a unique situation but it still uses Adobe PDF Reader and PDF technology, so I wanted to see if there are any PDF experts out there in advanced PDF scripting that may have any idea.  I'm not sure why fields hide in the initial processing, but then once its flattened they are no longer hidden.

[KJSTech]

I also just tried the opposite.  Initially mark the fields as hidden and change my test instead of = "" to !="" and mark them as not hidden.  Same result.  Looks great on screen but once the application flattens it, previewing or printing the flattened pdf file does not work properly.

[Bernd Alheit]

What software does flatten the PDF file?

[KJSTech]

Hi guys I did not realize there was a repose because I found the email alerts from this forum fail SPF so they go into our email filter quarantine.

forums_noreply@adobe.com does not designate 204.93.64.117 as

  permitted sender) identity=mailfrom; client-ip=204.93.64.117;

Anyway the software that is in question is IMM TotaleAtlas.  More about the company can be found here: https://www.immonline.com/

The process is done via an adobe reader frame inside Internet Explorer.  The site runs on IIS and is an asp.net web application.  I'm not sure what third party code they use, if its from LiquidOffice, Adobe, or if they wrote it themselves.

I was at a document design class a few years ago in Las Vegas and when we got into the more advanced PDF form design we touched on the PDF javascript abilities.  We did things like calculate fields, make a field dependent on another (like a field is read only unless an appropriate checkbox is selected), did mutually exclusive checkboxes, etc...

Honestly in my opinion I think they have a bug in the software.  I've finally convinced them to webex with me later today to get this looked at.

For you guys I just wanted to run that field hidden or not hidden javascript by some Adobe users who may be familiar with dynamic forms.  Perhaps some of you have done this in Lifecycle or other applications.  I'm not sure how it all compares but this is industry standard PDF format so I would think Javascript in one solution should work in another.

[Test Screen Name]

What does Preview actually do? still not clear what processing is server side, what is client side.

Since the preview shows bad, have you tried saving the preview and examining it?

[Test Screen Name]

Since you don't seem to actually know what software does the flattening, printing, preview delivery etc I'm going to speculate. It's probably a server component. It probably desks with form fields only. It probably utterly ignores JavaScript. No bug, that's probably its design. The bug would be setting up a workflow that relies on JavaScript when there is no specification that it will work. This needs detailed discussion of expectations. The programmers may not know anything about whether JavaScript is expected to be supported in their components but they can research it.

Bear at in mind too that if there is an activity of "flattening" this is not really considered to be like opening or filling or displaying or any other action. It's an entirely passive process dealing with the fields AS THEY ARE not as they would be if the form were opened. That's not a Bug.

[KJSTech · Accepted solution]

Ok after a support session this afternoon, the javascript works in processing only.  Their flattening process is proprietary.

A solution was to move the field off screen out of view and replace the on screen field with a new custom one.  So the one that the user sees is now called CSTM_LN_INS_OPT_PREM_AMT.  The original field LN_INS_OPT_PREM_AMT has been moved off screen.

Also those two date fields at the bottom were renamed to CSTM_C_LN_EFFECTIVE_DT and CSTM_CS1_LN_EFFECTIVE_DT.

The new code is below.  What its doing now is instead of hiding or unhiding fields, its copying the value of an exsisting field to the newly displayed field if the conditions match.

Any code you see below with _FLAG has to do with some check boxes on the form, so for this all intents and purposes can be ignored.  But the moral of the story is that this is a supported way to accomplish the same thing

function CSTMCheckBoxs()

  {

  var LN_INS_OPT_PREM_AMT = this.getField ("LN_INS_OPT_PREM_AMT");

  var CSTM_LN_INS_OPT_PREM_AMT = this.getField ("CSTM_LN_INS_OPT_PREM_AMT");

  var DP_FLAG = this.getField ("DP");

  var LN_GAP_AMT_P = this.getField("LN_GAP_AMT");

  var GAP_FLAG = this.getField("GAP");

  var LN_MBP_AMT_P = this.getField("LN_MBP_AMT");

  var MBP_FLAG = this.getField("MBP");

  var C_NAME_P = this.getField ("C_NAME");

  var CS1_NAME_P = this.getField ("CS1_NAME");

  var LN_EFFECTIVE_DT = this.getField ("LN_EFFECTIVE_DT");

  var CSTM_C_LN_EFFECTIVE_DT = this.getField ("CSTM_C_LN_EFFECTIVE_DT");

  var CSTM_CS1_LN_EFFECTIVE_DT = this.getField ("CSTM_CS1_LN_EFFECTIVE_DT");

    if (LN_INS_OPT_PREM_AMT.value != "$0.00") {

        DP_FLAG.value = '1';

        CSTM_LN_INS_OPT_PREM_AMT.value=LN_INS_OPT_PREM_AMT.value;

          } else { DP_FLAG.value = '0'; }

  if (LN_GAP_AMT_P.value != "") { GAP_FLAG.value = '1'; } else { GAP_FLAG.value = '0'; }

  if (LN_MBP_AMT_P.value != "") { MBP_FLAG.value = '1'; } else { MBP_FLAG.value = '0'; }

    if (C_NAME_P.value != "")

      {

        CSTM_C_LN_EFFECTIVE_DT.value = LN_EFFECTIVE_DT.value;

      }

    if (CS1_NAME_P.value != "")

      {

        CSTM_CS1_LN_EFFECTIVE_DT.value = LN_EFFECTIVE_DT.value;

      }

  }

In testing this works both in processing and once flattened.  So this issue is resolved.  Thanks everyone for your participation and involvement in this thread as I unraveled Adobe JavaScript and how it works and does not work with our third party application.