I am trying to render a PDF via servlet,using Itext for getting PDF file.
Need to disable save ,print option in adobe pdf reader menu bar while other options like scroll,find should be there and in addition need to disable the file menu of the browser window in which it is rendered.
I have disabled print and file menu using below code
stamper.setEncryption(null,null,
PdfWriter.HideWindowUI, PdfWriter.STRENGTH40BITS);
stamper.setViewerPreferences(PdfWriter.HideToolbar);
Problem is
disable save button in Adobe PDF reader menu bar (using **Adobe Reader 9**).
We need to distinguish two different aspects: printing and saving.
You can encrypt a file and set the permissions in such a way that printing isn't allowed. However: if you only encrypt a document with an owner password, it is very easy to decrypt the document and to remove the restrictions. Encrypting a document with an owner password only works on a psychological level: for instance: you indicate that the original producer of the document doesn't want the document to be printed.
If you want to avoid that an end users saves a PDF document, you are asking something that is impossible. The only way to avoid that an end user doesn't have a copy of the PDF is by not sending him the PDF. A PDF can't be opened in Adobe Reader without having the actual bytes on the disk. Even if you would disable saving (for instance in the context of a web application), you'd always find the PDF somewhere in the temp files and people would be able to copy that file as many times as they want.
In your code snippet, you try hiding the toolbar (a viewer preference), but that doesn't make sense. Whether or not this viewer preference will be respected entirely depends on the PDF viewer. For instance: in Adobe Reader X and later, you have a special widget that appears when you hover over the document. This widget allows users to save the document.
Even with Adobe Reader 9, hiding the toolbar isn't sufficient: if the user chooses the appropriate menu item or hits the appropriate "hot key", the toolbar would appear and they could happily click the Save button. In addition, they could have right-clicked and chosen "Save" as well.
In short, you're asking the wrong question.
What you need to do is NOT prevent saving BUT control the actual use of the PDF and that's where DRM (Digital Rights Management) comes in. DRM however is usually very expensive, it requires a custom PDF viewer and it's out of the scope of iText.
Related
I am trying to render a PDF via servlet,using Itext for getting PDF file.
Need to disable save ,print option in adobe pdf reader menu bar while other options like scroll,find should be there and in addition need to disable the file menu of the browser window in which it is rendered.
I have disabled print and file menu using below code
stamper.setEncryption(null,null,
PdfWriter.HideWindowUI, PdfWriter.STRENGTH40BITS);
stamper.setViewerPreferences(PdfWriter.HideToolbar);
Problem is
disable save button in Adobe PDF reader menu bar (using **Adobe Reader 9**).
We need to distinguish two different aspects: printing and saving.
You can encrypt a file and set the permissions in such a way that printing isn't allowed. However: if you only encrypt a document with an owner password, it is very easy to decrypt the document and to remove the restrictions. Encrypting a document with an owner password only works on a psychological level: for instance: you indicate that the original producer of the document doesn't want the document to be printed.
If you want to avoid that an end users saves a PDF document, you are asking something that is impossible. The only way to avoid that an end user doesn't have a copy of the PDF is by not sending him the PDF. A PDF can't be opened in Adobe Reader without having the actual bytes on the disk. Even if you would disable saving (for instance in the context of a web application), you'd always find the PDF somewhere in the temp files and people would be able to copy that file as many times as they want.
In your code snippet, you try hiding the toolbar (a viewer preference), but that doesn't make sense. Whether or not this viewer preference will be respected entirely depends on the PDF viewer. For instance: in Adobe Reader X and later, you have a special widget that appears when you hover over the document. This widget allows users to save the document.
Even with Adobe Reader 9, hiding the toolbar isn't sufficient: if the user chooses the appropriate menu item or hits the appropriate "hot key", the toolbar would appear and they could happily click the Save button. In addition, they could have right-clicked and chosen "Save" as well.
In short, you're asking the wrong question.
What you need to do is NOT prevent saving BUT control the actual use of the PDF and that's where DRM (Digital Rights Management) comes in. DRM however is usually very expensive, it requires a custom PDF viewer and it's out of the scope of iText.
I need to print a PDF/A document with my Java App, which implements iText 2.1.7. When I use a PDF Templates, my app works fine and print the checkbox checked if they satisfy the conditions.
But, when I use PDF/A Templates, my app doesn't fill these checkbox, but they receive the values correctly.
Can anyone help me? I dont know if this problem is in the template or in the code.
Can you describe in more detail what you are doing?
thesis I:
If you have a (non PDF/A) PDF with form fields and then you programmatically change a checkbox value with iText then the change is visible in the PDF (e.g. you can see it in adobe reader and on printed paper)
Correct?
thesis II:
If you have a PDF/A compliant PDF and change the value of a checkbox then the change is not visible in the PDF (neither in adobe reader nor on printed paper)
Correct?
In the PDF format you need to differentiate between the appearance of a field and the (data) value of a field. Normally PDF/A documents are made for long term archiving and not to change values. If you still do that you need to ensure that you also update the appearance of a form field.
Try to update the appearance of the field you change (after you set the new value). You can do that with the following method:
AcroField fields;
boolean success = fields.regenerateField(String yourCheckboxFieldName);
I'm trying to generate an xsl to be printed in a pre-printed sheet which works fine.
Now i want to give the user a better previsualization (in the pdf screen version) adding a background image which emulates the "pre-printed" stuf on the sheet to give the user a "context" of what is he printing.
The question is: Is there any way I can set a background image in xsl (using apache fop) visible only in pdf but not in the printed version of it?
Thank you all for reading or givin any advice.
Although as the comments state, you can't have content in the PDF that does not come out in a physical printed copy, here is one possible work around for you. Depending on how your users are ultimately going to be using FOP for PDF rendering and how your a driving the work flow, it's possible to pass a parameter into an xslt file before the transofrmation phase is run, so potentially, you could do a dual rendering of the same PDF, one that is presented to the user where the background image is enabled, and one that gets printed, you could just set a variable similar to how they do in this Example, and call it something like $isPreview, and just use a simple if or choose statement to check for 'Y' or 'N'.
Since you are sending to a printer, you may even want to take advantage of FOP's ability to generate to Postscript rather than PDF, I've used this feature quite extensively for print documents using FOP while also producing a PDF copy for electronic delivery via email or hosted services, and I've yet to find any discrepancy between the PDF rendering and what is printed after sending a rendered postscript file, so it should work well for you as well.
As I said, this is not truly a solution to your problem as you've presented it, but as a work around, it could get you the desired results if your clever about how you implement it.
I don;t think the statement that it is not possible is true, I am just not sure how to create such a PDF with FOP. Certainly you can add an image field. One would use a button field and place the image in the button. Then you would set the properties of that button to not print (printable false).
PDF support images in fields: https://answers.acrobatusers.com/adding-image-field-form-q41825.aspx
RenderX supports PDF Form fields but I do not see where they support an image inside the button, only text: http://www.renderx.com/reference.html#PDF%20Forms. But they do support setting a field to "printable".
Using JSP and Jasper Reports, I made an application for printing A4 label pages.
I have to configure my application (set alignment on the PDF page to be generated) according to different pages (2×5, 2×7, 3×10 and 3×11 grids), different printers (Kyocera, OKI and HP) and different PDF viewers (Adobe, Foxit and Nitro).
Example: I set in Jasper Reports an A4 page with a grid of 2×5 and an user who has Foxit Reader will print it on a Kyocera. If another user has Kyocera too but is using Adobe Reader, the space between the columns gets smaller. But if the user has Foxit Reader but will print on an OKI, the whole document goes left and even gets cut.
To configure each individual label page is unavoidable, but can it be possible for me not have to set the page alignment for specific PDF viewer or printer (at least one of those)? It can be a way to skip the PDF generation or some conventional configuration that all printers would interpret - to get my page printed exactly the same, regardless of PDF viewer or printer.
Are you sure this is not a setting in Foxit Reader and/or Adobe reader that is causing the issue?
I know in Adobe reader there is a setting in the print dialog under Page Sizing & Handling. They should use Actual Size so as to not do any scaling or manipulation of the image.
In Foxit Reader it is under Print Handling. You need to set Scaling Type to None. The default seems to be Fit to Printer Margins.
You should not have to do anything different for each PDF reader and/or each version and combination of printer. That is a maintenance nightmare you should not try to take this on. You would have to make changes every time they bought a new printer, and potentially when an upgrade to their reader comes out.
Best bet is to figure out why they are producing different results, and tackle that issue, instead of brute forcing the problem. I am pretty sure this is more a training issue with your users, and telling them about these settings should clear up the problem.
UPDATE: After some more digging it seems to be possible to set the value of the Print Scaling while exporting. After you create your JRPdfExporter you need to set JRPdfExporterParameter.PRINT_SCALING to JRPdfExporterParameter.PRINT_SCALING_NONE:
exporter.setParameter(JRPdfExporterParameter.PRINT_SCALING, JRPdfExporterParameter.PRINT_SCALING_NONE);
I do not know if this will work for Foxit Reader also, but I would assume it would.
We have a java application which generates PDF forms which have at the footer 2 dimensional bar codes. The bar codes contain the companies form id and the customer id.
Now we are looking for a way to test the generated PDF automatically without a physical scanner. Means we just like to read the PDF via Java API, render & capture somehow internally the bar codes and read their content. So this is the rough idea.
The question if this approach is achievable? Does anybody know some APIs in Java which may able to do such a thing? e.g.
reading a PDF and rendering its content as an image in the background?
reading a bar code image and extracts its conent?
processing an image and extract text content (OCR)?