Optional flattening of the output pdf

[maxiride]

As of now the filled output pdf is flattened and this results in a new PDF with the form fields filled but not further editable. I suppose this has been a design choice.

Being not very knowledgable about PDFs, are there specific reason to flatten a filled PDF forms before saving it to disk?

I'd like to propose a PR where the flattening is optional so that the end user is still able to perform modifications if needed before printing and\or archiving.

It is my understanding that it would simply be needed to edit this section of the code like (on the spot brainstorming):

// Create the pdftk command line arguments.
args := []string{
    formPDFFile,
    "fill_form", fdfFile,
    "output", outputFile,
}

// Borrowing the setup used for the optional overwrite at line 106
if len(flatten) == 0 || !flatten[0]{
    args = append (args, "flatten")
}

[r0l1]

Being not very knowledgable about PDFs, are there specific reason to flatten a filled PDF forms before saving it to disk?

Yes, this was a design choice.

It is my understanding that it would simply be needed to edit this section of the code like (on the spot brainstorming):

Did you test to run pdftk without the flatten argument? Did it result into the desired output? If so, my proposal is following:

• Break syntax and replace overwrite with an optional Options struct containing the overwrite and flatten boolean flag.
• add go module support
• initial tag to v1

[maxiride]

Did you test to run pdftk without the flatten argument? Did it result into the desired output?

I did some tests with the fillable PDFs I have at hand with no issue, if there are edge cases I'm not aware of them.

[r0l1]

Alright. Willing to work on a pull request?

[maxiride]

Alright. Willing to work on a pull request?

I'll see what I can manage. I found an issue thought, unrelated to the flattening and it isn't a bug with this package but rather either with pdftk or how fillpdf invokes it so I'm not opening a new ticket as of now until I can get further infos.

Accented letters (àèéòù maybe more) are not printed to the final document. Were you aware of this issue\are there workarounds?

[r0l1]

I'll see what I can manage.

Cool!

Accented letters (àèéòù maybe more) are not printed to the final document. Were you aware of this issue\are there workarounds?

Values are written here. Try setting accented letters and examine the final FDF file. If they are present, then this is a pdftk problem. Could also be a problem with your OS and UTF8 handling... Which OS do you use?

[maxiride]

The values are correctly written to the FDF file. So it's indeed a pdftk issue. I've found this relevant question on stack overflow and I'll see if there is anything doable to "sanitize" the strings or change the FDF header as suggested there.

Honestly I know nothing about the FDF file and its configuration so if you have any idea or suggestion it would be more than welcome.

Which OS do you use?

Windows 10

[maxiride]

Implemented with #8

[r0l1]

Thanks. I adjusted the options handling. Never write to a global variable. This could lead to a race.

The values are correctly written to the FDF file. So it's indeed a pdftk issue. I've found this relevant question on stack overflow and I'll see if there is anything doable to "sanitize" the strings or change the FDF header as suggested there.

Thanks for the link. I added Latin-1 support. This seams to be supported by pdftk. Could you give it a try?

[maxiride]

I adjusted the options handling. Never write to a global variable. This could lead to a race.

I understand the change but the why is unclear, could you elaborate or link me relevant info to learn more about the issue?

---

I'll keep you posted about the accents. Thanks for giving it a shot!

[r0l1]

I understand the change but the why is unclear, could you elaborate or link me relevant info to learn more about the issue?

The Fill function might be called concurrently by multiple goroutines. Assigning to a global variable by multiple routines causes a race. For more info see: https://golang.org/doc/articles/race_detector

I'll keep you posted about the accents. Thanks for giving it a shot!

It works with German umlauts. Should also work for french symbols...