Printing GIF files from a browser - java

We are currently leveraging a third party tool to convert pdf files into gifs and displaying them in the browser. We have been adjusting the DPI of these images so that when printed they will look as close as possible to what the original pdf looked like. We've found that at least a setting of 300 DPI matches roughly the clarity of what the pdf will display when printed. However if we try to load a GIF image with a setting of 300 DPI into the browser using HTML the image is very large and causes scrolling. I was able to get around it by setting the height and width of the image tag, however when/if the margins on the Print preferences changes the image will be chopped when printed. If we print the images as is through an image viewer they print fine.
So that leads me to my question, is there some other third party tool that we could call from a webpage that would load these images and give printing capabilities through some sort of a Java applet?

I recommend to embed the PDF file inside your HTML page, so if you print, you have full capatibilies, and you don't need to "duplicate" que information.
If you have to use GIF images (for any reason), you could have two views, one small, wihout scrolls, for viewing the HTML page, and other only with the GIF image. When you click "Print" in the HTML page, you see a kind of "Print preview", larger, with scrolls or whatever.
Hope it helps.

Related

iTextPDF : Set page size of PDF according to the size of the image to be inserted

I am generating PDF report using iTextPDF for Selenium WebDriver scripts developed in TestNG.
The report would contain text block (String) and images. Images always contain a text block before it.
The issue I am facing is that while creating the document, the text block and image blocks are getting displayed in the wrong order of occurrence in the test case. I believe this is because the image to be inserted has size greater than the PDF page.
Consider a scenario where the order of occurrence in the test is as follows
Text Block1
Image1
Text Block2
Text Block3
Image2
'Text Block4'
But the PDF shows as
Text Block1
Image1
Text Block2
Text Block3
Text Block4
Image2
My code is not wrong. I have triple checked it.
No, I cannot post the code because it is huge (>500 lines) and is in my company system.
I want to know if we can create a PDF page and then change its size dynamically when I encounter that the image to be inserted is large.
Your code is not wrong. When an image doesn't fit and there's text that follows the image, adding the image is postponed. You can change this behavior by using the following line:
writer.setStrictImageSequence(true);
In this case writer is your PdfWriter instance.
This solves one problem: the sequence of the text and images will now be correct. However, due to the image size, you will end up with plenty of white space in your document because images that don't fit will trigger a new page.
You could try to solve this by changing the page size. This involves using the setPageSize() method as explained in my answer to this question: iText create document with unequal page sizes
If you want to match page sizes to image sizes, take a look at my answer to this question: Add multiple images into a single pdf file with iText using java
The Image class extends Rectangle and we can use an Image object as a parameter when we create a Document instance, or we can use an Image object when we change the page size:
document.setPageSize(img);
document.newPage();
Important: when you change the page size, the new size will only go into effect on the next page. You can't change the size of the current page (it has already been initialized and changing it after initialization might screw up the content that was already added).
Also: it isn't sufficient for you to change the page size to the size of the image because you're also adding text. You could use ColumnText in simulation mode to find out how much space you need for the text, and then use ColumnText once more to add the text for real after you've created a page with a size that accommodates for the text and the image.
See Can I tell iText how to clip text to fit in a cell and look for the getYLine() method.
I wonder if it wouldn't be easier for you to scale down the images so that they fit the page... Of course: if the size of the images can vary, you'd have the risk that large images would become illegible.
P.S. All the answers I refer to are also available in the free ebook The Best iText Questions on StackOverflow. I bundled hundreds of my answers in this book so that I could easily search for already answered questions when answering a new question.

Transparent images are showing up as black boxes after xfa.fillXfaForm. Are transparent images supported for the xfa fill?

Here's the current problem:
I have an XFA Form created by a 3rd party and I would like to use it as is.
I was able generate the PDF with filled fields by:
a) Extracting the XML via Acrobat Pro
b) filling the fields within the XML and calling
XfaForm xfa = form.getXfa();
xfa.fillXfaForm(new FileInputStream(XML));
What I'm trying to do is just stamp an image/watermark over the 2nd page which has a form w/multiple fields. The "DRAFT" png image I'm stamping has a transparent background so if the overlay works, the image background should make the underlay appear and look like that the image text is sitting on top of the pdf page.
What I wanted to accomplish would have been trivial if this was not an XFA form. I would just use iText's pdfStamper and stamp this transparent PNG over the 2nd page, but since I'm now confined to use Adobe LiveCycle Designer, I noticed that this once trivial task in the non XFA document isn't so trivial within XFA.
From a previous post, I learned that I couldn't mix technologies together. I had to choose between nonXFA (AcroForms) vs XFA (built by Adobe LiveCycle Designer). Basically, I couldn't do a fillXFA then use the stamper, so I had to figure out how to do this using XFA.
I've tried the following steps as a static PDF and a dynamic PDF....it didn't make a difference what type the PDF was.
1) Within Adobe LiveCycle Designer, I went to the second page of the source PDF and defined 2 image fields.
overlay1 - this will span the top portion width of the page which has text
content underneath
overlay2 - this will span the lower portion width of the page which has text
content underneath
2) As a test...I selected an image for overlay1 which has a transparent background and it's
foreground background as DRAFT
At design time...the DRAFT transparency image worked and it was laid on top of the content correctly
for the imageField: overlay1.
I saved the modified XFA-based PDF, opened it up in Acrobat Pro, and exported the XFA XML structure.
I verified that overlay1 had the DRAFT image as a base64 encoded string.
<overlay1 xmlns:xfa="http://www.xfa.org/schema/xfa-data/1.0/" xfa:contentType="image/png"
>iVBORw0KGgoAAAANSUhEUgAACWAAAAJYCAYAAADmY91UAAAACXBIWXMAAC4jAAAuIwF4pT92AABH
.......
.......
3) When I took the same base 64 string and only entered it's content within overlay2 and rendered it through the fillXFA method...the image was a black box instead.
I also opened the file in Acrobat Pro, then double clicked on the imageField area, selected the transparent image, and it still showed up as a black box.
I repeated the previous step with an image w/no transparency and it's rectangular white background
overlayed everything underneath it.
4) I went ahead and made another image...one that didn't have any transparency.
DRAFT with no transparency and it's background is white.
I had it encoded in base64 format.
I was able to place it within both overlay1 & overlay2 image fields without any problems.
The new problem is that the white background of the DRAFT images covered everything behind it.
Why did the initial transparent png work during the Adobe LifeCycle Design (design time) and after
a fillXFA call it shows up as a black box? But if I change the image to not use transparency at
all...everything works?
Does XFA not support transparent images for image fields during an xfa fill? Remember, it worked during
design time when I told Adobe LiveCycle designer to use this transparent png for this field.
I'm basically trying to create 2 image watermarks over a specific page within an XFA pdf.
My current backup plan is to flatten the PDF (take off the XFA) and putting back all the fields back on the form using Acrobat Pro and filling it using the standard PDF itext calls and using a stamper (this is going to be tedious since there's a bunch of fields). But I'd like to know if anyone ever had to do the same w/an XFA PDF form before I look at option B.
So I replaced the same PNG transparent image with a GIF transparent image. The GIF image encoded in base64 worked. I can create a new GIF file w/transparency, encode it in base64, and replace the previous one & it still worked. Looks like a bug with PNG rendering within the XFA form

Jpeg to Svg and Image Tracing

Currently we have a requirement where we have an image depicting the blueprint of the mall (red specifies the booked up areas and white specifies the available areas) and the image is available in a raster (JPEG) format.
We would like to drag and drop some icons onto the available areas of the image (in white). There should also be zoom in and zoom out functionality to be given for the above image as well
Since the JPEG has a lossy scaling, zooming after a certain limit can result in a jagged image. One proposed solution is to convert the image to SVG (Scalable Vector graphics).
Going with the expanded form of SVG, it simply tells us that image is:
s=>scalable (i.e. you can zoom to any level without compromising the quality)
v=>vectorized (i.e co-ordinates are available)
So by simply looking at the XML format of the image, we can predict whether to allow dropping an object at fill=red or fill=white where red and white are the two colors in the image. This might not be appropriate solution, but I'm just guessing it this way
Now the problems I see with this approach is:
Converting an image with some open source tool (InkSpace) - if we trace it with ink-space, which uses portace inside it to trace the image, it can handle only black and white colors.
Note-: Most of the tools comes with some license.
Problem with inkspace is that it embeds the image into the SVG map and does not create the co-ordinates. If you trace it with inkspace, it only creates the outline of the image.
Converting it with some online utility - Not recommended in our case, but doing so results in a large size of the SVG image. For a 700 KB file, the SVG generated is about 39 MB, which when opened up on a browser crashes the browser.
Most of the time when the image is converted to an SVG, it becomes way too large a big factor to worry about. There are utilities available like Gzip to compress files, but this is a two way route - first you convert, then you compress.
Using delinate (which employs a portace and autotrace engines in it) - the quality of the image produced is not good.
Using Java code - Again the quality suffers. Java graphics are not fully developed to handle the conversion (size is again way too large)
Converting the image to PDF, then to SVG - this also embeds the image into the SVG file, which is useless as no co-ordinates are available
Does anybody got any idea on this ,how to deal with this situation?,Can we handle the drag and drop on raster(jpeg,png...etc) images itself?
Thanks
Dishant Anand

Scrollable Image in PDF

Looking for tips/tools to make this happen (using PDF/Velocity Templates/Java):
I have an image that has large dimension (4000 x 2000) and that image is obviously not viewable in a PDF. I can modify the size of the image to fit into the PDF.
But what I want to do is to view the actual size of the image in the PDF. I want to be able to scroll the image from left to right.
How can I keep the true size of the image, without destroying the set container size of the PDF?
That's not quite a basic PDF feature, but it might be implementable using some embedded scripts inside the PDF, assuming that the user has a PDF viewer capable of running scripts.
Now, a PDF is not supposed to be used as a dynamic document where you can scroll. How would that work on paper after printing? If you want scrollable documents, then you should stick to HTML. I strongly advise you not to try to do this.
If, however, you still want to go down this route, then here are a couple of suggestions:
As I said, you could do it with embedded JavaScript, but then it depends on how you're generating the PDF: FOP, iText, another PDF writer library, or just plain println concatenation, since few libraries support embedding JavaScript.
You could just make the image fit into the page, but keep its original resolution, so that you end up with a high resolution page that the user can zoom in and scroll. This way you leave the scrolling to the PDF viewer itself, you'll just have to let the user know that the image has a higher resolution and should be magnified. And frankly 4000px isn't that large, it's not even enough to keep up with today's standard printer DPIs.

Java-generated PDF renders fine on screen, but does not print correctly

I'm generating a complex PDF from a swing application by printing my JComponent.
This PDF is created by getting a proxy Graphics2D object from an iText PdfTemplate object.
The PDF is viewable on-screen, but when printed in banner mode on a Lexmark 4650 from windows printing cuts off after the fourth page, with most items not being printed.
Is there a good way to look at the contents of the PDF to see if something is out of line? The PDF seems to be larger than it needs to be, given the information it contains.
Or, a way to get a useful error from the Lexmark printer?
Download the PDF File
EDIT 2011-10-18 13:45:00 PST: replaced PDF with a smaller version with less PDF shape data. Still not printing correctly.
Here is the output from the printer. You can see that printout cuts off shortly after the 410 depth.
We have seen printing fail when there is not enough memory - printing needs a much bigger raster than screen. Does increasing memory help?
There was a rendering issue where a line was being drawn to a coordinate of Integer.MIN_VALUE, this made the printer very unhappy.

Categories