Ability for Labview to import/export data with a PDF Form

[moswalt77]

This was issue number 7737579.

I wanted to be able to export and fill in the fields of a PDF Form.

There is already the ability to work with Word, Excel, and various other data bases, but a PDF Form is not supported.

I know there are other ways to skin this cat, but in my case, we have many PDF Forms already made that are test reports.

To have Labview run the test and insert values into the named fields of an existing PDF Form seemed like a no-brainer to me.

Anyway, that is my suggestion for you guys to chew on.

Thank you,

Michael

[JimB.]

This would be incredibly useful.

My company also uses PDFs for existing documents, many of which have form fields to allow our operators to fill them out electronically. It would be fantastic to be able to automate this.

Unfortunately, the methods I have found for doing this are at odds with the fact that these are password secured PDF files. Using Adobe Reader we can open the files, fill out the form fields, and perform a Save As to store the completed form, all with the password remaining intact. Unfortunately, the third party tools I've found to automate this either won't work with password protected files (despite security settings allowing for filling of form fields) or don't respect the password at all and result in the modified PDF file having the security removed.

[wiebe@CARYA]

I think this would be more in place for a 3rd party toolkit (like my own, we actually get this request fairly often). AFAIK, It's not as well documented as the rest of the PDF specification.

[moswalt77]

@wiebe

I do not fully agree.  Labview already has some basic ability to interface with Microsoft Office documents (Word, Excel, etc.).Adobe PDFs are as widely used as those, at least where Testing is concerned.  There is certainly room for third party programs to offer a more refined interface experience.  But I think a basic ability to read from/write to a PDF form would be a very helpful native ability in Labview and not be out of place along side its present native abilities dealing with MSOffice.

[wiebe@CARYA]

---

@moswalt77 wrote:

I do not fully agree.  Labview already has some basic ability to interface with Microsoft Office documents (Word, Excel, etc.).Adobe PDFs are as widely used as those, at least where Testing is concerned. 

---

I wouldn't expect you to (or you've wouldn't posted it I imagine).

If it helps (probably not), I think that MS Office API should have been modules as well.

If everything being useful (to who?) ends up in LabVIEW, we'll end up with 3% usefulness and 97% overhead.

3rd party might have been a misnomer. Add-on would have been better.

[moswalt77]

On reflection of our conversation, I think Labview should include basic tools that are of service and are useful to the programmers. And I think this should include some basic ability to read from/write to a PDF form because a PDF form is increasingly a basic tool of Labview programmers.  I qualify this as my own opinion.  I agree that there are others who use Labview that have no need of or use for PDF forms at all.

When I started Labview, it was rev 3 (Rev 4 came out very quickly after I started) and I had a need to interface with Excel. I discovered there was a way to read from/write to Excel using Dynamic Data Exchange (DDE).  I suspect that ability was included as native in the basic Labview program because it was recognized that Excel was (and still is) a valuable tool for some Labview programmers (like Test Engineers such as myself).  So I feel there is a precedence in providing some basic interface ability into Labview for PDF forms.

However, you bring up a valid point about usefulness vs. overhead that I had not considered this before. I further suspect that perhaps NI’s way of dealing with this was to create Tool-Kits of functions that provide a deeper resource for a specific subject.  We as Labview programmers can pick and choose the Tool Kits that we would find useful and thus keep our overhead somewhat manageable.  The Report Generation Tool Kit comes to mind as one that expands on the ability for my program to interface to Excel.  I can see perhaps a PDF Tool Kit that would let one not only populate forms but create them on the fly.  Or mass-upload form data, or other things I have not the imagination to think of yet.

I would thank you for your time and your responses, wiebe. Through it, I have managed to distil and sharpen my own idea of what I would like to have included in future Labview releases.

[AristosQueue (NI)]

This request falls pretty firmly in the category of things I don't think NI should be doing -- and that customers are better off if NI *does not* do them. I also think the Report Generation Toolkit was a mistake. Toolkits like those are outside of our core mission. They're useful, yes, but they are forever second-class citizens when it comes to allocation of resources for maintenance and feature additions. If we have a developer who can get support for either one more feature of MS Word or one more DAQ device, guess which one gets picked? On the flip side, if a smaller company or even a lone developer develops such a tool and makes it available on the Tools Network, it can be a major product for them, one that gets the tender, loving care that software needs. So unless a toolkit is critical to a major slice of NI revenue, I tend to think it is a bad idea for us to try to do it, at least in the LabVIEW distro itself. We have several internal developers who have built toolkits on the side and made them available, but that's not really NI doing it.

Having said that, what products we develop is not my call, so I'm just going to leave this idea open and see the kudos that develop.

[moswalt77]

@AristosQueue

My apologies for replying so late. I wanted to respond sooner but work and real life got in the way.

I disagree in that developing a toolkit with the ability to interface with 3^rd party program (like MS Office or PDF forms) is something that NI should not be doing.  Granted that NI should not lose sight of the ‘core’ function of Labview: developing a program language that simplifies interfacing with instruments and performing a test program.  Part of its ability is to allow a programmer to create a graphic interface (GUI) that allows some organization to control of instruments and the information it senses.  What I am trying to say is that it is not enough to simply make it easy to create a test program, which Labview does, but it also must be able to collect, save and present the data in some meaningful way so a person can analyze and come to some conclusion.  Having some basic interface abilities to work with Word, Excel, or (as I would like) a PDF Form should be part of the core function of Labview.  This is why the Report Generation Toolkit is valuable.

I think I see your point about NI development of the Report Toolkit as a mistake because it diverts NI resources (I apologize if I have mis-interpreted this), but by this token, the application engineers who man the phones are also not directly contributing to the maintenance and development of new Labview features. (I recognize this is a broad statement and there may be a few who man the phones AND spend time with maintenance/development duties. But from my interaction with them, it seems that the vast majority spend their time helping people like me on the phone or email.)  But their presence is critical to me and is part of the reason I maintain Labview and NI hardware in my test systems.  Having that resource available has been a godsend.

I think I have prattled on long enough. I find it hard to stop once I get started because so many other good arguments come to mind once I get started.  Still, Aristos, thank you for your response.