I have a 2-page PDF that I want to overlay information on (think of a form that someone manually fills out) using a C#/.NET Windows application. After this form is generated, it will need to be previewed and printed (exported into a graphic or PDF is nice, but not a requirement).
At first glance, I'm thinking of two ways to do this:
Use a PDF manipulator like iTextSharp, take a copy of the blank PDF form, and add text to the PDF. Then, launch Adobe Reader to do a print or preview.
Convert the PDF into a graphic, and put the graphic into a C# Report. Then, overlay text fields onto the report, and use a .NET ReportViewer control to preview and print the report.
The text does not need to be searchable or copyable or have any of the cool things that PDF gives me, so I'm leaning towards the second option. Am I missing anything, or is there something I'm not thinking of? Thanks in advance.
We use #1 extensively and it works perfectly. You shouldn't have any problems, it's rather easy (just need to make the fields writeable and use a FDF file and merge it with the PDF file). At least that's how we did it.
Related
I have a PDFthat has text boxes in it. My program uses Xfinium PDF software to fill the text boxes. When I view the filled in PDF the document shows up with no data in the fields. I have tried using QLPreviewController and UIWebView and they both do not display the filled in fields; however, if I email the document to myself and open it in Adobe DC on the iPad all the data shows up correctly. It may be important to note that even the mail app does not show the PDF correctly filled in.
Here is the PDF opened in Adobe on iPad
Here is the PDF opened in UIWebView in my app (also shows same way in QLPreviewController
PDF forms may bring along appearances or may rely on the viewer to create an appearance for the value of the field.
Fairly complete PDF viewers (like Adobe Reader or Foxit) can get along with both variants well. Incomplete viewers, though, like many so called previewers, require an existing appearance and display empty documents for forms which do not bring along appearances.
Thus, if you want your forms to be visible on incomplete viewers, too, provide appearances.
The QLPreviewController use the CGPDF* API to display the PDF files. The CGPDF* API has some limitations, it displays only the page content and it does not display annotations, no matter if they have appearances or not. Form fields use widget annotations to display the field content so they are also not displayed.
The solution here is to flatten the form fields. This operation will transform the form fields into page content and QLPreviewController will display the final file correctly. The downside of this operation is that the form fields are no longer editable.
The XFINIUM.PDF library creates apearance objects for field values. The problem is related to iOS PDF rendering engine which does not display annotations and form fields. The solution is to flatten the form fields if you want to view the files using the QLPreviewController.
The form fields are flattened with this line of code:
pdfDocumentObject.Form.FlattenFormFields();
Disclaimer: I work for the company that develops the XFINIUM.PDF library.
Both QuickLook and UIWebView/WKWebView uses Apple's internal and undocumented CorePDF framework, which has no code that would render PDF AcroForms (doesn't matter if backed by appearance streams or not)
You can either
1) Flatten the document on the server or with a client-side library.
2) Re-implement everything from scratch and add support for PDF forms. (See Page 431ff in Adobe's PDF Specifications - "Interactive Form Dictionary")
We did (2) in the commercially available PSPDFKit SDK. It doesn't use Apple's rendering engine as you do not have a way here to render appearance streams for PDF form widgets, so even with a lot of code you'll not be able to get the representation that is encoded in the document. For this you'll either have to result to private API or re-implement everything yourself. We also support (1) using the PSPDFProcessor class.
Thanks,
It works for me.
pdfDocumentObject.Form.FlattenFormFields();
Bala.
We are generating PDFS from a web app a couple different ways, ItextASharp, Html->Rotativa, and RDLC...
Is there any way in anyof those tools to modify the ViewerPreferences dictionary inside the PDF so as to disable the "shrink to fit" option..
The PDF format supports this option, I've found documentation for that...
I'm aware that not all viewers honor the request not to shrink to fit, but we're using stock adobe readers across the board so it's ok.
I was able to find this in ITextSharp to read one, modify it and save, it, so I have to believe there is a way to set it before generation...but I can't find it..
Determine properties such as if PDF is Simplex or Duplex in iTextSharp
It'd be awesome if Rotativa had a way too...since we use that for some reports
We also have some done in RDLC style, if there is a way to do it there...
The reason we have to do it, is one of our apps prints labels and the amount of data leave no room for fudging it. Printing them from a web app is problematic, even when we control the ecosystem.
Unfortunately, our IT group will not use the reg settings to change the default on the machines.. we have to do it through code.
I am developing application wich produce a report with graph. I read about free C# libraries to create PDF but I can't see any completely FREE geenrator to use in application that I want to sell. Can you give me one?
Other problem is to generate a simple chart. What are the tools to create such a graph? I need to put it into pdf document after generating it.
Thx for help!
PDF reporting could be done using nfop. I know someone who has done PDF with that, but I do not know more.
Regarding the charting: you could use Microsoft Chart controls, render to an image and include an image in the PDF.
This is my first stackoverflow question.
After days of research, I am still lost on how this can be done, if its even possible.
I am trying to create a PDF document using either iTextSharp or XSL-FO (FO.NET is what I am using currently). Creating the documnet is no problem. I need this documnet to have fields that the user can still fill in.
I am aware of the ability to create a PDF form using acrobat, then using iTextSharp to fill in those fields. This can then be saved and the user can open the document and edit it.
The problem with this is, anytime the PDF "template" needs to be changed, someone has to edit the PDF document, then change the backend logic to handle the new field.
I am looking for a 100% dynamic solution.
Ideally I would use XSL and FO to create this document without the need for an exisiting PDF document. I have found no way to create a fillable form using FO.NET, or even iTextSharp, without already having an exisiting PDF "template".
Thanks in advance.
I believe both the RenderX XEP and Antenna House FO processors support PDF Forms. They aren't free and additional output modules may be required for PDF Forms.
I've searched Stackoverflow and google and found many ways
how I can print stuff in C#.
The best way for me would be to populate blank white windows form
with some label, textbox and picturebox elements and print it as a windows form.
This way is very poor because it prints in 72 DPI, and is not flexible for multiple
pages print.
Next way that I found that would be good is using iTextSharp, but there is a problem
that iTextSharp only generates PDF-s, and you have to open it in PDF viewer and print
from there.
I love this way of thinking where I create a paragraph, and then fill it with text and graphic, so I found this thread
http://www.devarticles.com/c/a/C-Sharp/Printing-Using-C-sharp/
where it discusses how to create your own printing engine in C#, something like iTextSharp,
but very lightweight...
Now that I've said that, I want to know is there any ready to use printing engine that would be like iTextSharp, made for printing, not for PDF generation? What is the best way to print something, without using reporting services like CrystalReports.
I think Crystal Reports wouldn't work for my case cause I don't want to print generic reports, but some text and graphics that I need to dynamicaly generate every time I need to print.
I found that it was much easier to do printing using the printing stuff in WPF.
EDIT
XPS is the page description format that Microsoft included into .NET with .NET 3.0. It is nominally part of WPF, and is integrated with the WPF form layout model. But you can create XPS documents in memory and send them to printers, from any .NET app, including a WinForms App.
An example:
http://statestreetgang.net/post/2008/03/Creating-an-XPS-document-in-memory-via-the-DOM.aspx
It is approximately equivalent to the iTextSharp capability you explored, except:
you can do it all in memory if you like, no need to save to a filesystem file. Of course if you want to save to a filesystem file, you can do that too.
you don't need an external viewer in order to start the print.
If you are new in programming and you have some data like from Data Base, and you want to print it after retrieving it from Data Base. Then just follow this link it will guide you step by step.
Print Data in Dot Net (C#,Vb.net)