Acrobat Reader does not display values filled by HummusJs pdf-fill-form

[tonybranfort]

I'm trying to figure out why Acrobat Reader doesn't display values filled with HummusJS and pdf-form-fill.js. I can open the pdf in Chrome and see the filled field as expected but not when I open in Acrobat Reader. Clicking in the field also does not get the value to display.

Using:

• The code in this sample (HummusJSSamples/filling-form-values) latest commit (6261ead). With one modification: .TD(0,4.5) added to writeAppearanceXObjectForText in pdf-form-fill.js to fix alignment as per Filled Text Position Off #12. But same issue even without that modification.
• Adobe Acrobat Reader DC Version 2018.011.20063
• Chrome Version 69.0.3497.100

Pdf with filled field (2.a. Family Name of Attorney)
g-28-out.pdf

[zzzzMaDaOzzzz]

Having same issue here.

[tonybranfort]

Is it possible it's due to being an XFA form? Ran across this:
https://stackoverflow.com/questions/24149361/form-field-values-set-with-pdfbox-not-visible-in-adobe-reader

I don't know yet if these government forms are XFA.

[galkahana]

It is definitely one issue. This form is XFA, and therefore the XFA data must be edited in addition to the AcroForm data. This issue can be solved by adding an XFA editing implementation. i'll see how hard this is an might add it.

Another thing is that this document is encrypted and got extensions. it might be that this means that this document is only meant to be edited in acrobat manually and not filled automatically. that is - to do this one has to learn how to override the encryption and extension. which may be considered hacking, and in any case may be hard to learn how to do.

I'm gonna try to improve the form filling sample code, but it might just be that i won't be able to resolve this issue, especially if implementing XFA support wont be enough. I think it might not be enough...because if it was, then i think dropping XFA should have been enough...and i tried this and still the form didnt show up properly.

b.t.w you can see that chrome ignores the whole encrypt/XFA elements, cause it shows the text fine. especially if using the new options i'm providing here to let the code use a system font and some known graphic options:
https://github.com/galkahana/HummusJSSamples/tree/improve-form-filling

[tonybranfort]

Outstanding. Thanks for looking at this Gal. Please let me know what I can do.

[galkahana]

I merged improve-form-filling branch as i'm quite busy with other stuff, and it should be worthwhile to some of you.

The merge allows you to provide default text options (size, color, font) to use when filling text fields.
This should improve:

1. text positioning (for those of you for whom the text sits too low). This also solves Quad support (text alignment).
2. less chance that the text will not appear when not in focus. The provided font will be used to create the out-of-focus appearance, and there's no reliance on the embedded font (which possibly doesn't have the right glyphs, or just encoded in some sophisticated anner).

There's still XFA update to handle, and whatever encryption issues to solve, and this is just one font for the whole form...and doesn't allow to use multiple per what's required by the specific field, but using this thing should help more forms into the fold.
this - https://github.com/galkahana/HummusJSSamples/blob/master/filling-form-values/main_g28.js#L12 - shows an example. you provide an extra options structure and in it defaultTextOptions which value is text options, like what you'd provide to writeText (https://github.com/galkahana/HummusJS/wiki/Show-text)

[galkahana]

k. slight progress here.
My solution from 7 days ago had an error, which meant that with the sample forms (and probably others), the default text options font was not correctly included in the form. so i fixed it.

now, if i remove the XFA form....acrobat complains, but THE FORM LOOKS GOOD. it doesn't if i keep the XFA.

so...there's room for optimism. if i can "fill" the XFA form with values, this might be a solution.

with this extra enthusiasm, i'll try to see if i can patch something quick for that...if anyone wants to help, please do.
Gal.

[galkahana]

k. additional.
A simple prototype. just wrote the XML required as an XFA dataset with what i assume was the right values....outcome creates a good form with no complaints from Acrobat.
So it's now clear the only TODO is to update the XFA form values.
Things is XFA format is ~1500, has nothing to do with PDF.
So. i'll see if i can reverse engineer here so i don't have to read everything, otherwise...there's still a wait till i get some time to do this....unless someone wants to do this instead, ahem ahem. e.g. someone with an actual project, and not just doing this for exercise.

branch is here:
https://github.com/galkahana/HummusJSSamples/tree/forms/wip

[tonybranfort]

Fantastic Gal :) Can you point me toward how I open the door to the XFA? Remember that you're talking to a PDF neophyte. I really know about next to nothing on PDFs but if you can point, I can start swinging. Really appreciate your time and effort on this.

[galkahana]

just look it up. XFA has nothing to do with PDF.

[galkahana]

you know what, i just saw another post with yet another someone not contributing code to the lib. im tired of this. im tired of ppl not learning what they need. tired of me having to do eveyrthing for other people who actually have projects. im done with this. enough.

[tonybranfort]

I totally get it Gal and I'm really sorry I triggered that. I didn't understand that XFA wasn't part of PDF but I'm checking it out. It's very clear that your contributions have helped many. We all develop our technical niches but I can tell you that PDF seems to be one area that seems to be lacking active ongoing opensource contributions from those that really know how they work - which is why I was very glad to run across HummusJS. But maybe now we're seeing why it's especially hard to keep those projects going. I get it.