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".
Related
I want to make a program that is able to read PDF files and parse it's contents.
Thus I need to extract the text using some kind of library. I found 3 ways to do so.
OCR libraries (like Tesseract)
ScanPdf libraries (like iText)
Converters from PDF to text.
I fail to understand the big differences between them since all of them will produce in the end a text file from the PDF. So which is the best way to go about this?
PDF is a complex format. If you open a PDF and you're staring at a bunch of text, that doesn't really tell you much. It could be that you're staring at an image file someone decided to wrap into a PDF file. This is 99%+ certain what you have if someone scanned a document and told their scanner to 'scan to PDF', and 100% certain what you got if you have a PNG or JPG and 'save as PDF', or try to 'print to PDF' such a thing.
There is no text in the PDF then. There are pixels.
To turn pixels into text, that's where OCR libraries come in. That's what they do. That is all they do. It's an AI bonanza and error prone. No guarantees.
However, PDF is more complex than that, it isn't like PNG/JPG: It's more like HTML. You can put actual text in there.
This has different issues, though. You can place text blobs (i.e. a 'rectangle', with coordinates, and then the text that is supposed to go inside). Again a lot like HTML: You can do something like:
<p class="foo">
World!
</p>
<p class="bar">
Hello,
</p>
and then create CSS so that the foo is rendered after the bar block (can be as simple as .foo, .bar { display: block; } .foo {float: right}).
Turning that HTML into "World! Hello," is not all that tricky. Realizing that during a render, you end up seeing "Hello, World!", and thus writing code that returns "Hello, World!", that's way more complicated.
The same problem applies to PDF. For simple PDFs, extracting the raw text inside is not too difficult, but be aware that for even mildly complex PDFs, the text can arrive in a jumbled mess.
iText is trying to give you enough power, at least, to provide the latter: To give you a full hierarchical breakdown. It returns 'here is a text box, here is its positioning, and here is the text inside. and now here is another text box, etc'. It does not return a big string.
In other words: The answer depends a lot on what PDFs you have / what PDFs you expect to be able to read, and how complex they are. If they are scans, you need an OCR library. If they are simple, a basic pdf2text converter will do fine. If you want to attempt to take into account fancily positioned PDFs with forms inside and 'popups' that can be opened and closed, oof. Probably all these tools are insufficient and you're signing up to many personweeks worth of effort.
There definitely IS text embedded PDFs, it is NOT just pixels.
It depends on if the PDF is a "true" PDF (ie you can highlight the text and copy and paste it elsewhere) or if the PDF is a scanned image.
With scanned images, you'll have to use an OCR API. All of the major cloud providers have OCR APIs (ie Amazon Textract, Google Document AI, Microsoft Form Recognizer, etc). If it's a true PDF, then I've found the pdf.js library (https://mozilla.github.io/pdf.js/) quite helpful in doing a direct text extraction.
Just know that doing this only gets you the text that is literally on the page, and there's quite a bit of work still to do to get key/value data fields programmatically across many documents.
This is something that my startup is working on (www.sensible.so/) too if you're interested in something more powerful!
Let me start off with saying that I've seen some questions in this regard but nothing actually specifically answering my issue.
Let's say I have a template version of a PDF received by someone else. It's a classic PDF that looks like a form but only one part is editable, the other parts are not because they are being filled in with data from an imported excel sheet. (Sadly I can't show an example)
I've been able to do most in iText 7 but I can't figure out for the life of me if I can change a flat text field into an editable form field, like on image 1.
Image 2 shows checkboxes that I want to make editable as well but I can only change their value within java and even then it only shows a cross, not a checkmark (even if I change the checktype).
It's a bit hard to explain but tl:dr is that I just want to know whether I can edit an existing flat PDF in java or if I have to do so in adobe itself.
Thanks
I want to know if there is any solution for the following scenario:
I have an application which uploads the files, after scanning and transcoding them, onto a server. Suppose, an image file is being uploaded which has been tampered with some additional contents over it. Now, as the uploaded file is illegitimate, I want to remove the additional tampered contents and upload just the original part of this image file. Is it possible to do so in Java?
Thanks.
It's not possible to detect in the general case, but there are some heuristic methods available to determine whether an image has been edited. Try using the tools at http://imageedited.com/ to get an idea of what's possible.
Removing the edit is a much more difficult problem, which is probably impossible with current methods.
I'm just speculating here, and I don't know how well it would work in practice, but you could do it if you limit to specific sources of tampering. E.g., suppose you want to remove the logo added to an image by memegenerator.net.
You know in advance what the text looks like and where it is. Create a transparent png template that matches the text. Then sum the differences between the image and template pixel colors, multiplying each by the alpha of the template pixel. Since for this particular logo, it's basically white (although it seems to have a thin black shadow) you would get false positives for a picture with a white part there, so you'd also need to verify that the surrounding pixels are (within a tolerance) not white. It's not clever but it could work for certain sites.
For anything more flexible (e.g., logos on images which have subsequently been resized) you're in to the territory of OCR and TinEye-like image matching, which are more advanced than I could advise you on.
To correctly detect all kinds of "tampering" and filter "illegitimate" from "legitimate" in general, you'd need an artificial intelligence that could understand the meaning and context of what it's seeing. The short answer is: you can't. That's what humans are for.
If this is for a website, probably the best thing you can do is a report button that lets users of your site report images that don't fit with your site's rules.
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 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.