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.
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'm attempting to perform some string validation against individual PDF pages in a file via the use of Apache PDFBox.
I'm going to be utilizing PDFTextStripper for the majority of this, so my first issue to tackle was the fact that all the PDFs i'm going to be validating against are generated as 2up; e.g Page 1 of 2 and page 2 of 2 were on the same page or if you imagine you literally scanned a book face down into a scanner - In addition to this, they were oriented incorrectly, and needed rotating 90 degrees so PDFTextStripper could read them properly.
Using elements of the below questions/solutions, i have built a method which first crops the page exactly in half, exports the cropped pages in order to a new file, rotates each page to the correct orientation and then saves the file;
Rotate PDF around its center using PDFBox in java
Split a PDF page in two parts [duplicate]
Visually, my method is seemingly working as expected until i run PDFTextStripper against it - It appears to be returning the text of not just the page i want, but also the page i cropped out of it.
To confirm the issue, I extracted a single page out of the entire document and saved it as a new file - when running PDFTextStripper, i still get the same results even though all i can see is literally one page. Adobe search doesn't bring up the hidden, legacy data either.
I can only assume that during my transform method, i need to redefine the cropped page with only the contents of the cropped page.
My question is, how can i do this?
p.s - i haven't posted my code as it's basically a amalgamation of the solutions provided in the aforementioned links above - however if it i needed, i can provide
The PDFTextStripper ignores the CropBox you set to crop the pages. It also ignores whether text is covered by some filled rectangle or image or whether the text is invisible, it extracts all text (except text in patterns or contains in Type 3 font characters).
You might want to try the PDFTextStripperByArea instead. This class (which is derived from PDFTextStripper) restricts itself to regions you can define.
(Unfortunately these regions have to be defined using a different coordinate system than the one used for the CropBox, so usually you will have to transform the coordinates first.)
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".
Is there a way to micro-adjust exactly where a PDF prints on a page within IText?
Here's my problem: It appears that naturally through variations in printer manufactures or age of printer, etc., minor variations occur when printing a PDF document. These variations are typically very small, however for 2 sample printers (both laser and the same model and manufacturer) the variation in text placement is upwards of 1-2 millimeters between printers. This would be fine for most normal printing however, for this task, this is outside of acceptable tolerances.
My gut reaction to this is to provide some ability to make micro adjustments to exactly where the print happens and thus be able to account for any variation within the printers themselves. Printing does appear to be consistent for all jobs sent to a single printer however.
Presently I have a PDF created in Adobe Acrobat Pro X that has form fields, that are then filled out by a java application and sent to the printer.
Thank you for any and all suggestions
My first attempt to solve this issue would be to try changing the default settings of the printer driver... somehow. But I can't give any useful pointers about that.
If you want to adjust the PDFs, you should probably change the page boundaries to shift the content. For example, this code shifts the content of the first page 50 units down, for a simple PDF that has only a MediaBox.
PdfReader reader = new PdfReader("in.pdf");
PdfStamper stamper = new PdfStamper(reader, new FileOutputStream("out.pdf"));
PdfDictionary pagedict = reader.getPageN(1);
PdfArray mediabox = pagedict.getAsArray(PdfName.MEDIABOX);
mediabox.set(1, new PdfNumber(mediabox.getAsNumber(1).intValue()+50));
mediabox.set(3, new PdfNumber(mediabox.getAsNumber(3).intValue()+50));
stamper.close();
You'll have to adjust any other boxes (CropBox, BleedBox, etc) accordingly. Take a look at the PDF spec for information on the different page boundaries.
We have a requirement where we already have pre printed stationery and want user to put data in a HTML form and be able to print data on that form. Alignment/text size etc are very important since the pre-printed stationery already has boxes for each character. What could be a good way to achieve this in java? I have thinking of using jasper reports. Any other options? May be overlay image with text or something?
Also we might need to capability to print on plain paper in which case the boxes needs to be printed by our application and the form should match after the printed with the already printed blank stationery containing data.
Do we have some open source framework to do such stuff?
Jaspersoft reports -- http://sourceforge.net/projects/jasperreports/
You will then create XML templates, then you will be able to produce a report in PDF, HTML, CSV, XLS, TXT, RTF, and more. It has all the necessary options to customize the report. Used it before and recommend it.
You will create the templates with iReport then write the code for the engine to pass the data in different possible ways.
check http://www.jaspersoft.com/jasperreports
Edit:
You can have background images and overlay the boxes over it and set a limit on the max character size ... and many more
It is very powerful and gives you plenty of options
Here is one of iReport's tutorial for a background image http://ireport-tutorial.blogspot.com/2008/12/background-image-in-ireport.html
The big problem when printing form content that has been filled in electronically, is aligning it correctly on the pre-printed form. You may get content to align for one printer, but when you use another it is completely misaligned.
Fly Software have a form design product called InForm Designer that gets around the problem nicely by allowing users to specify and save vertical and horizontal offsets for printers. This ensures filled in form content is always aligned. I've tried it and it works perfectly. Take a look for yourself here...
http://www.flysoftware.com/products/inform_designer/overview.asp
It might be worth implementing a printer offset similar to InForm's in your own application (if possible).
Some things to think about.
First in terms of the web page, do you want use the stationery as the form layout?
Does it have to be exact?
Combed boxes (one for each character)
Do you want to show it like that on the web page, or deal with the combing later.
How are you going to deal with say a combed 6 digit number. Is this right aligned. What if they enter 7 digits. Same for text. what if it won't fit.
Font choices, we had a lot of fun with W...
How aligned do you want the character within the box, what font limitations does that imply, some of the auto magic software we looked at did crap like change the size of each character.
Combed editing is a nightmare, we display combed, but raise an edit surface the size of the full box on selection.
Another thing that might drive you barking mad, you find find small differences in the size and layout of the boxes, so they look okay from a distance but a column of boxes sort of shifts about by a pixel. Some of testing guys had to lend us their electron microscopes, so we could see how many ink molecules we were out by. :(
Expect to spend a lot of time in the UI side of things, and remember printed stationery changes, so giving yourself some sort of meta description of the form to start with will save you loads of trouble later on.