I am using Adobe life cycle designer to create docs in my application....I have all my documents in word and I use the export to option in Adobe Life cycle designer and i get the document converted and now I need to have a user fill in the exported document..so can some one please suggest me how this would go and we use the java script behind....
You could have them fill the form in Adobe land, then use the scripting method exportData to get the form data as XML, then inject that XML into your Word docx as a custom xml part.
From there, Word will use the XML in any content controls bound to it.
Related
I'm in the process of exploring the possibilities of Word VSTO add-in. Using a combination of custom task pane(s), a custom ribbon and a series of dialog boxes or forms I can collection information from the user. However, what I can figure out is where I can persist this information within the document. A docx is made of a series of individual files, how do I add my file within the cab as well? Storing the custom info outside of the document is not an option, it must travel with the document itself.
Thanks,
Update : If I use custom xml parts per the solution mentioned here https://msdn.microsoft.com/en-us/library/bb608612.aspx then it appears to me that the xml data is visible to the user. See screen shot. The user should not be able to browse data that my add-in is storeing - not because it's senstitive but because it makes no sense for them to see and interact with a bunch of serialized class data.
You can store your custom information inside the document using so called Custom XML Parts. This information is stored within the document.
Here is an example how to add a Custom XML Part to your document:
How to: Add Custom XML Parts to Documents by Using VSTO Add-Ins
In our application we are using Itext Pdf 5.5.3 library.
We have checked with some of the pdfs in which Checkboxes displayed correctly(check/uncheck) .
However there are some pdf with RadioBoxes and do not display radiobutton(on/off) correctly.
I also use this link to validate pdfs and java code
String[] values = form.getAppearanceStates("Checkbox");
return null values.
Also tried Itext RUPS and found that pdf which are working shows Form Field Names in RUPS Form Tab. And PDfs which are not working do not display form fields.
I tried generating pdf from word document and it doesn't display form fields in RUP , neither I can check/uncheck checkbox in Adobe Acrobat Reader.
What could be the solution to display radiobutton with check on / off ?
Edit -
I had created sample web application to reproduce the issue.
Please setup attached web application and let me know the fix for the issue.
Please download from this link
You have successfully discovered the difference between interactive PDF forms and "flat" PDF documents that look like a form to the human eye, but that aren't interactive forms.
To make the "flat" forms interactive, you need to open those flat documents in PDF editing software (e.g. Adobe Acrobat) and you need to add a form field manually.
You can ask Acrobat to guess where it should add fields, but Acrobat will be wrong in many cases for obvious reasons. You always need a human if you want it to be done correctly.
As for creating an interactive PDF from Word... Forget about it. Use OpenOffice or LibreOffice.
I've an application that automatically fills MS Word templates (.dotx) written using COM and Word object model. There are some Bookmarks in the template, that are filled programmatically.
Now I'm migrating to OpenXML.
Could you please explain me what should I prefer using OpenXML - Bookmarks or Content Controls and why?
WordDocumentGenerator is an utility to generate Word documents from templates using Visual Studio 2010 and Open XML 2.0 SDK. The code is available for download at http://worddocgenerator.codeplex.com/. Content controls are used in templates. A lot of samples are provided for document generation which will show how functional and flexible content controls are.
Content controls are significantly more resistant to overwriting during document editing. You can use either one with OpenXML without additional complications.
We have some custom print code to print an Infopath form on the user's default printer as well as a server-based PDF printer for loading into a document management system. This is working perfectly, but we would like to control the name of the generated PDF file. The PDF print utility can automatically generate a file name using various parameters such as file name, current date/time, etc. Since we cannot programmatically interface with the PDF print utility, the easiest way to control the name of the generated file would be to set the file name in InfoPath and allow the utility to append a date/time stamp.
I have tried setting the form caption as described in the forum thread here and setting the Save As file name as described in the forum thread here, but regardless, the PDF print utility still uses the default form name (Form1, Form2, etc.). Is there another way to set the form name in code?
Thanks in advance for your help!
Have you considered using an InfoPath PDF Converter that you have more control over via a Web Services API?
Have a look at the PDF Conversion Services as well as the PDF Converter for SharePoint. It deals quite well with InfoPath.
Some additional links
Converting using a Web Service call
Converting InfoPath files from a workflow.
Note that I have worked on this product, so I am obviously biased. It works great though.
Are there any good alternatives to Adobe Acrobat for creating interactive PDFs? The terminology is a little fuzzy here - by interactive, I mean "able to be filled in", and not necessarily "scriptable". So this form would be for data collection, rather than report generation which seems to be the common scenario for pdf-related questions on SO.
The trick is that they need to be fillable using Adobe Reader. For those who have not experienced the many frustrations of Acrobat - by default, Reader cannot fill in a form unless it was created using Acrobat Pro >8.0 and has specifically enabled usage rights. That's fine and it basically works (except then Pro users can't save their data - WTF?).
Because I am getting frustrated, I would ideally like to avoid Adobe products altogether (that is on the design side, for the users Reader is still a necessity or I would just do it as a db-backed web form). I'm wondering if anyone has has good experiences with alternatives? Either software libraries or products?
Thanks!
EDIT - Thanks, matt b - I'd seen iText before but didn't know it could create forms. Unfortunately, it looks like Reader cannot save filled-in data to the forms generated by iText (or generated by OO Writer). I've got the nasty feeling that what I want is fundamentally impossible except using Adobe's own rights management tools. If there are other ideas. I'd love to hear them.
You can create fillable form PDFs using OpenOffice.org as well as LibreOffice.
To create the initial form elements in the *.odt documents, enable the View --> Toolbars --> Form Controls tools, which allow you to add clickable checkboxes + radiobuttons, fillable text fields, pushbuttons and some more to the page(s).
When you're finished with your document, use File --> Export as PDF with the checkbox Create PDF form enabled.
Now your PDF form will be editable (and saveable!) with any non-Adobe PDF viewer.
NOTE, however: Adobe uses an own proprietary way to create and fill PDF forms. Adobe Reader does only support to fill PDF forms which were created by an Adobe product (and which have been assigned 'extended rights' so Reader can indeed save the formdata alongside the document).
Adobe Reader will not work with PDF forms you created with OpenOffice.org or LibreOffice ('work' in the sense of: 'allows you to fill+save the form data'.). The technical mechanism behind this is that Adobe digitally sign their form documents with their own key (which is known to the Adobe Reader, and which you agreed to not reverse engineer when you accepted the Adobe Reader EULA...). --
This means:
Non-Adobe PDF Readers will not be able to 'fill+save' forms created with Adobe products (they can 'fill+print' them however).
Adobe PDF readers will refuse to 'fill+save' forms created with non-Adobe products (they will 'fill+print' them however).
The latter two points will be true for all the tools and utilities mentioned in the other answers to this question. If I'm mistaken here, please let me know in a comment...
iText is pretty much the standard in the java-world for generating PDF files programmatically. Perhaps it can also be used to create PDFs with forms in them as you would like?
The open source page layout tool Scribus has a bunch of features oriented to creating interactive PDF forms. I haven't personally used them, but they appear reasonably complete and are covered by the tutorial.
Scribus is worth knowing about if you ever need to do serious page layout in any case.
XSL FO is some thing we used to create PDF files out of existing form data. Unless you want the fillable pdf to be sent out the client, this is a valid option.
IText lets you create Annotations (there are essentially 3 types of 'interactive' components - forms (old style FDF and new XFA) and Annotations. Acrobat and lots of third party tools should let you modify the Annotations values.
There is also a DotNet version of IText called ISharp - both are freeand extremely powerful.
CutePDF Pro allows you to turn a PDF into an interactive form.
Foxit reader allows you to save any pdf with the filled in fields.
I recently dabbled with Scribus. I found it to be an excellent tool if one has enough time to configure and play around with it. I highly recommend it. Wufoo is also very good.
I am not a fan of Acrobat / Adobe. A software should make my life easier not challenge me at every step.
If you search the net with these keywords - FREE FORM CREATOR and you can add the word HTML5.
You will find an array of sites where you can log online and all your clients can have their separate login, fill in data and the form remains in the Cloud and declutter your hard drive. All stakeholders can access the form and edit at anytime. The account can be used as a folder for your business. These forms can be accessed on any device and any platform.
Many of these forms are HTML5 driven, they are so beautiful and fluid. Keep away from macros, they carry viruses.
www.homebasedofficeservices.com