-1

I am having a strange problem with iText and acrofields. I created a PDF and added the acrofields. Now when I do form.setField ('a field name', "a value") and I display or print the PDF, the value gets duplicated (once in smaller font and once in the intended font for that document). I checked the structure of the document and it doesn't look that my Acrofield are duplicated. What could be the cause of this

Thanks in advance

Pascal

Please find link here: https://drive.google.com/file/d/0B8O5n5QFSSNrSGVlNllOcEJHRzQ/edit?usp=sharing

I am on Ubuntu. Maybe that's why! I am using evince to look at the file, however I get the same result when I print it. I included a screenshot of what I see. https://drive.google.com/file/d/0B8O5n5QFSSNrWXJyY2VpSkt5NE0/edit?usp=sharing When I say duplicated, I should say shadowed. The value of the field is first displayed without font styling then overwritten with the required font.

The code I showed is pretty straightforward. The 2 arrrays are the name of the fields and their associated values. If the value is xxxx I set the field value to its index in that array. As you can see on the screenshot it gets shadowed too. My printout looks exactly like the screenshot. I haven't tried it yet on another platform.

Here is the code written in groovy

    File mergeForm (String path, Map fields, Map values, String newFile) {
    println "Merge Form: $path"
    def file = grailsApplication.mainContext.getResource(path)?.inputStream

    if (file == null)
       return null

    def reader = new PdfReader(file)
    def stamper = new PdfStamper(reader, new FileOutputStream(newFile))
    def form = stamper.getAcroFields()

    fields.eachWithIndex { k, v, i ->

        def val = ""
        if (v instanceof Closure) {
            val = v(values)
        }
        else if (v == '_xxxx_') {
           val = "${i + 1}"
        }
        else if (values[v]) {
           val = values."$v"
        }

        println "setting value[$i]: ${val} to: $k"
        form.setField (k, val)
    }

    stamper.close()
    return new File (newFile)
}
Pascal DeMilly
  • 681
  • 1
  • 6
  • 16
  • Can you supply a sample document and a code sample to reproduce your issue? – mkl Feb 03 '14 at 05:17
  • Thanks for taking the time. I updated my question with a file and some code – Pascal DeMilly Feb 03 '14 at 08:19
  • I've opened the document with Adobe Reader and I don't see the duplicated fields. Can you be more specific? I haven't seen this behavior before (except when viewing a document in a poorly implemented PDF viewer). – Bruno Lowagie Feb 03 '14 at 08:26
  • @PascalDeMilly I obviously do not know which new values your `fields` parameter tries to introduce. Thus I tested filling that form by setting the value of each field to the trailing 5 characters of its key name. The result looks as expected. Thus, please provide actual key-value pairs the setting of which makes the PDF look bad. You might furthermore also want to supply a sample output illustrating the issue. – mkl Feb 03 '14 at 10:14
  • I am on Ubuntu. Maybe that's why. I am using evince to look at the file, however I get the same result when I print it. I included a screenshot of what I see. https://drive.google.com/file/d/0B8O5n5QFSSNrWXJyY2VpSkt5NE0/edit?usp=sharing – Pascal DeMilly Feb 03 '14 at 11:36
  • I have updated my question with more info and a screenshot of what I see. Thx – Pascal DeMilly Feb 03 '14 at 11:45
  • It looks like your PDF viewer tries to generate an appearance for the fields itself but still also displays the appearance streams generated by iText, and unfortunately they create the appearances differently. Please supply the already filled-in PDF for inspection. BTW, which iText version do you use? – mkl Feb 03 '14 at 13:10
  • I just could reproduce the issue using evince on a virtual machine. Due to the age of that vm it is an ancient evince version, though, 0.6.0. Which version do you use? – mkl Feb 03 '14 at 13:33
  • Thanks for looking into this @mkl. Here is a link to an empty pdf with acrofields set: https://drive.google.com/file/d/0B8O5n5QFSSNrWjV5ZVRtczhpYk0/edit?usp=sharing – Pascal DeMilly Feb 03 '14 at 13:34
  • I am using evince 3.4.0 on Ubuntu 12.04 LTS. But the same problem exists when printing so it is more than a problem with evince. The problem may be when I created those acrofields. Maybe I missed something. BTW I use iText 2.1.7. Also if I flatten the stamper, I get the same result. stamper.setFormFlattening(true) – Pascal DeMilly Feb 03 '14 at 13:48
  • Arg, I just saw that the reason for duplicate field values are duplicate fields... I'll explain in an answer. – mkl Feb 03 '14 at 14:16

1 Answers1

0

Summing it up

The issue seems to be due to multiple field annotations in the PDF at hand for the each field which differ somewhat, though, and therefore have different appearances.

In detail

Looking at the document version BOE-267-L1-Rev-1.unlocked-with-fields.pdf we will inspect the topmost field on the first page, "This Claim is Filed for Fiscal Year 20". We see that the page object 9 in its annotations array (in object 265) has (among many others) object 304 and object 180 which both are annotations of that field!

304 0 obj
<<
  /Ff 12582912
  /MaxLen 2
  /F 4
  /Type/Annot
  /Subtype/Widget
  /T(This Claim is Filed for Fiscal Year 20)
  /P 9 0 R
  /Q 1
  /MK<<>>
  /FT/Tx
  /Rect[166.765 693.57 188.965 701.479]
  /DA(/Arial 8 Tf 0 g)
  /AA<</F 333 0 R/K 334 0 R>>
>>
endobj 
...
180 0 obj
<<
  /Ff 0
  /F 4
  /Type/Annot
  /Subtype/Widget
  /DR<</Font<</Helv 2 0 R>>>>
  /T(This Claim is Filed for Fiscal Year 20)
  /V()
  /AP<</N 179 0 R>>
  /P 9 0 R
  /BS<</W 0.5/S/S>>
  /FT/Tx
  /Rect[165.4 706.28 187.6 714.19]
  /DA(/Helv 0 Tf 0 g )
>>
endobj 

The definitions of these describe slightly different positions on the page:

  /Rect[166.765 693.57 188.965 701.479]
...
  /Rect[165.4 706.28 187.6 714.19]

and different default appearance strings

  /DA(/Arial 8 Tf 0 g)
...
  /DA(/Helv 0 Tf 0 g )

Thus, it is not a surprise that you get multiple, non-identical appearances of this field. The actual surprise is that the version filled by iText on Adobe Reader does not display double values.

@Bruno someone might want to look into this as soon as there is some time.

The other fields have duplicate appearances, too; most often the page positions are nearly identical, though, but the default appearance streams still differ which results in multiple, non-identical appearances for them, too.

mkl
  • 90,588
  • 15
  • 125
  • 265
  • I originally downloaded that file from: http://assessor.lacounty.gov/extranet/lac/control/binaryGet.aspx?uploadid=519 But it is locked (acrofields exists but cannot be saved), I used pdfunlock to unlock it (don't know how to do it with iText) and then wrote a small program to reinsert the acrofields. Now I see that in the unlock version without the fields there are still referenced (did a grep as I don't know pdf file format) to those fields (but not as acrofields I guess, they start with /TU). How can I get ride of them? – Pascal DeMilly Feb 03 '14 at 15:40
  • *then wrote a small program to reinsert the acrofields* - I assume you'll have to fix that program... ;) – mkl Feb 03 '14 at 16:06
  • I guess. I am just confused with Acrofields and Annotations. For example after I unlocked the file, I am left I think with annotations. When I add my acrofields, it doesn't overwrite the annotations (note that I don't even know if that the correct semantic) – Pascal DeMilly Feb 03 '14 at 16:43
  • Actually, if a file is locked, removing that lock may be acting against the will of its author. On the other hand, if the author explicitly allows you to use his document as you want or the software you use does not support the fine grained permissions of PDFs, it might be acceptable. Newer iText versions support a flag for ignoring the owner password. – mkl Feb 03 '14 at 18:54
  • Thanks @mkl. Actually that form is from a public government site to fill a welfare exemption. I am programming it for a non profit and need to fill the fields so they can print it. Not sure why they lock that file as it is supposed to be filed and printed. What functions should I look into to remove that lock or how can I remove annotations with itext so I don't get that shadow. Thx – Pascal DeMilly Feb 05 '14 at 21:16
  • I ended up using qpdf to remove the encryption. Nice and easy. Thanks for helping – Pascal DeMilly Feb 15 '14 at 17:15