I am not sure if this is an avoidable byproduct of FillPDF, but I notice that it is breaking the ability to fill out the form.
In my particular instance I have uploaded to my configuration a PDF which contains a form with calculations and all that fancy acrobat stuff. It works correctly from the desktop. Once it is uploaded though and subsequently downloaded via a link so that most fields are populated, the form can no longer be filled out.

I was hoping to use this as a way to help pre-fill some forms, but at the moment that does not look to be possible.

Comments

wizonesolutions’s picture

Status: Active » Closed (works as designed)

Hi Peter,

This is how Fill PDF works - it flattens the end result PDF. Maybe someone would be interested in submitting a patch for other functionality, but this module is generally intended for those forms that have strict templates and where all the information to be filled in can be collected beforehand.

Are you using the service, iText or pdftk for filling your forms, as this would affect if a patch could help or not?

peterparker’s picture

At the moment I am using the paid for solution offered by the module creator.

wizonesolutions’s picture

Yeah, so then this is something lefnire would need to look at. I'd contact him at http://fillpdf-service.com/contact

lefnire’s picture

i'll look into soon

lefnire’s picture

Title: FillPDF destroys PDF Form » Allow non-flattening option
Status: Closed (works as designed) » Active

How bout we just make flattening of forms an option, default checked? I'll look into

wizonesolutions’s picture

Sounds good to me. Maybe overridable via the $_GET parameters, e.g. flatten=1 or flatten=0?

If you can update the service and the Tomcat stuff I can update it for pdftk.

lefnire’s picture

ooh, I like that $_GET idea better. Ok, sounds good -- I'll try to hit that up tomorrow.

wizonesolutions’s picture

Yeah, I think both would be the best of both worlds so people don't have to put in the flatten=0 all the time and such.

peterparker’s picture

I'll just chill out and watch how this evolves. Thanks a lot.

wizonesolutions’s picture

Version: 6.x-1.9 » 6.x-1.x-dev
Category: bug » feature
Issue tags: +upstream

lefnire: any luck implementing this in the service and in the Tomcat service? If you can do that part and tell me what to change in terms of the API calls in the module, I could make the changes in the module, add the option, etc.

It's easy enough to implement for pdftk anyway, but not sure if I should do that before you take care of things on your end.

peterparker: If you start using the pdftk option for some reason and want it sooner, let me know :)

wizonesolutions’s picture

OK, so I've long since taken over the whole thing, and oh, guess what! The service is now using pdftk! So I'll try to work this feature in at some point. I'll look into implementing it in the Tomcat servlet as well...just in the interest of feature parity...though I'm not sure if I'll be successful on that.

wizonesolutions’s picture

I committed this already, but here's a patch with the new feature.

I didn't add an option for it; I just added a parameter to the URL. You can pass flatten=0 to leave the fields editable. For example:

fillpdf?nid=3&fid=28&flatten=0

If you are calling the code directly, an additional parameter has been added to fillpdf_execute_merge. Have a look at the module to see.

This will be available in 6.x-1.x-dev when it regenerates.

This is currently only confirmed working with pdftk. It should work with the service too, but I'm still making some changes service-side to ensure that.

After that, I'll probably mark this fixed. I don't even know if I have the architecture to run the Tomcat setup, and even if I fix it, I don't know how to rebuild the jar that easily. If someone is actually using this, patches or prodding is welcome, but I'm assuming the vast majority of people with their own servers will want to use the pdftk option and avoid running a whole 'nother service for such minimal gain. I might even phase out the Tomcat option entirely when I start a new branch.

Correct me if I'm wrong :)

wizonesolutions’s picture

Confirmed that this works with the service. Wow...it's really time for a new release, isn't it? I think I'll release a supported beta soon and make it official if no one logs issues against it.

wizonesolutions’s picture

Status: Active » Fixed
wizonesolutions’s picture

Version: 6.x-1.x-dev » 7.x-1.x-dev
Status: Fixed » Patch (to be ported)

Whoops. This actually needs to be ported as well.

wizonesolutions’s picture

StatusFileSize
new766 bytes

This broke compatibility with Fill PDF Service. I've changed the new call to merge_pdf_enhanced so that people on the stable release can keep using the service. Patch attached.

frankfarm’s picture

I confirm that the version of Fill PDF 6.x-1.x-dev I downloaded today addresses this issue when adding flatten=0 to the URL and when using fillpdf-service.com. My only additional feature request is that editable=1 or keepformfields=1 is more intuitive to me than flatten=0. If this suggestion comes too late or is not popular, then flatten=0 is fine. At least it works the way I need it to -- that's really what counts. Thanks!

wizonesolutions’s picture

I'd like to keep it somewhat obscure since it's not the way that most people would want to use it. The logic is that "by default, the PDF *is* flattened" so you're basically telling it not to do that.

I think it'll be equally intuitive any way because people are going to have to look up how to do it anyway :)

wizonesolutions’s picture

This has been pushed to 6.x-1.x now and will be in 6.x-1.x-dev when it regenerates.

wizonesolutions’s picture

Status: Patch (to be ported) » Fixed
StatusFileSize
new3.63 KB

This had no good patch to port, but I created a patch from what I ported this time. Requires previous recent patches (see commit list to determine).

ErnestoJaboneta’s picture

Is this ready for D7/pdftk? I can't get my pdfs to not flatten.

https://example.com/fillpdf?fid=24&nid=53&flatten=0

Edit:
I was able to get around it by switching around all the "$flatten = TRUE" to "$flatten = FALSE" in the fillpdf.module. But otherwise, it didn't work.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

wizonesolutions’s picture

@ErnestoJaboneta - not sure if you were not using the -dev version or something, but it works in D7. If not, please open a new issue.

  • Commit 60358a2 on 7.x-1.x, 7.x-2.x, 7.x-2.x-tests1, 7.x-1.x-ubercartbackporttest by wizonesolutions:
    Issue #920766: Allowing producing unflattened PDFs.