Inspiring

Answered

Javascript correctly hides fields on screen but not when printed

Forum|Forum|8 years ago
June 19, 2017
6 replies
4686 views

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.

This topic has been closed for replies.

Correct answer KJSTech

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.

T

Test Screen Name

Legend

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.

K

KJSTechAuthorCorrect answer

Inspiring

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.

T

Test Screen Name

Legend

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?

T

Test Screen Name

Legend

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

K

KJSTechAuthor

Inspiring

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.

K

KJSTechAuthor

Inspiring

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.

T

Test Screen Name

Legend

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?

K

KJSTechAuthor

Inspiring

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