I'm trying to render an auto-generated PDF in SWT and am getting gray-boxes at the same location and of the same size as the original images in the PDF. I'm using the latest libraries, found in "jPodRenderer.5.0.20081218". The problem also occurs when I render the files to a PNG image through the example code "de.intarsys.pdf.example.rendering.swt.RenderDoc.java" (and also occurs with the awt variant).
The same PDF can be viewed in Acrobat's Reader without errors, but I'm not sure if the PDF has errors (and Acrobat is just robust), or if JPod can't render the embedded image for some reason, or if I'm just missing something.
For comparison, I've tried two ways of generating the PDF (from its XML source):
1. via a Firefox plug-in called "commandlineprint" (which produces the PDF for which JPod Renderer draws grey-boxes)
2. opening the file with Firefox and using Adobe's PDFPrinter to create the PDF (this version has no problems, the images are rendered correctly by JPod).
I was wondering what limitations are there for JPod to render images. i.e. do they need to be represented in the PDF in a certain way? Does the PDF need to be complaint to a certain standard (/A,/X) or version (1.4,1.5,...)?
If anyone's willing to look at the source PDFs and resuling PNGs, I'd be more than happy to e-mail them.
Thank you & Happy Holidays.
Yes, please send me the file.
You might be seeing a bug or your PDF might use some construct that is simply not implemented in jPodRenderer.
There are a lot of variations in image rendering, for example
* encoding (PDF raster image, JPEG, JBIG2, CCITT...)
* color space (device, ICC, Lab,....)
* rendering mode (plain, mask, ....)
* representation (embedded image, image object)
While we believe that the current version has made some significant improvements (mostly on the CCITT images), there are for sure still some images out there we can not render.
You can inspect the different outputs yourself if you want some insight in the different generators using the COSBrowser feature of CABAReT Stage.
jPod SHOULD be able to render all images, so if you could provide us with an upload of your failed PDF, we'd be happy to fix it.
Thank you for offering to take a look at the original PDFs. I have attached them and the resulting image files I got from running "de.intarsys.pdf.example.rendering.swt.RenderDoc.java".
testwrite1_clp.pdf - A pdf generated via a Firefox plugin called "commandlineprint".
testwrite1_clp.pdf.0.png - The image rendered by RenderDoc.java from "testwrite1_clp.pdf". (has Gray-Boxes)
testwrite2_acrobat.pdf - A pdf generated from Firefox by printing to Arobat's Adobe PDF printer.
testwrite2_acrobat.pdf.0.png - The image rendered by RenderDoc.java from "testwrite2_acrobat.pdf" (looks good).
Both PDFs display correctly in Acrobat.
Thank you again for offering to take a look.
- Happy New Year,
- David Wang
P.S. Thanks for creating the jPod and jPod renderer libraries. I have only used them for about a week, but it works great.
Thanks for sending me the PDF.
What your tool generates is in fact something that is not implemented in jPodRenderer. The image is not embedded as a simple image but as a pattern color space.
There are different types of pattern color spaces. This includes linear or radial gradients (called shading in PDF) and a more complex one where an image is to be repeated in a tile pattern until a specified rectangle has been filled. The only pattern color space that's implemented is the linear gradient.
Your generator has created a pattern color space for the image and set the rectangle to be filled to the image's dimensions, so it is drawn exactly once. Any pattern color space not implemented causes the affected area to be filled with a light grey color. That's what you're seeing.
The methods to implement would be AwtGraphicsEnvironmentAdapter.createPaintPatternPaint() for AWT and SwtGraphicsEnvironmentAdapter.createResourcePatternPaint() for SWT.
Thanks for the quick response. I'll have to decide whether it would be better for me to figure out another pdf-generating method, or to implement createResourcePatternPaint().
I'm not well versed in the library yet, but if I can/do come up with a implementation, I will certainly post it back here. However, I suspect if it were simple enough for me to figure out, it would have already been implemented.
Hello. I ended up trying to implement the createResourcePatternPaint(). While I have hacked-together a brittle solution that will fulfull my purposes, I came across a problem that you are probably aware of, but I thought I should mention just in case.
As quick summary, this 'problem' specifically applies to the use of jPod Renderer's SWT rendering ability (I haven't tried AWT).
I'm still very much a novice with both understanding the jPod libraries and the PDF spec, so forgive me if I missed something...
SwtGraphicsEnvironmentAdapter's "createResourcePatternPaint()" method returns an SWT Pattern object. This works fine for the sister method "createResourceShadingPaint()" because Pattern has a constructor for linear-gradients that allows one to specify the start and end coordinates. However, Pattern's constructor for images (tiling images) does not allow the user to specify a starting offset. As a result, even though the images that make up the tiling pattern can be scaled, the entire Pattern cannot be shifted/translated during construction. As a result, a corner of an image will always reside at the graphic context's (0,0). (Incidently, Pattern also doesn't have a constructor for radial-gradients, so I can understand why that hasn't been implemented yet.)
This is not a problem when...
Referring to the PDF specs: This is not a problem when the PDF Tiling Pattern's attribute/key "Matrix" (a transformation matrix) is identity, but could be a problem if it's not identity, and therefore requires the pattern be shifted. (And also, if the image is skewed, and therefore needs to be tessalated - but I don't know if the PDF Tiling Pattern allows tiling of non-rectangular images)
This could be worked around...
This could be worked around by applying a translation transformation to the "CwtSwtGraphicsContext", prior to drawing the pattern. However, setting such a translation through CwtSwtGraphicsContext's setTransform() method also translates the shape that the Pattern is trying to fill (see CwtSwtGraphicsContext's fill() method, specifically the line "gc.fillPath(path)", which attempts to fill the shape 'path' with the GC's current background color/pattern). Therefore there needs to be extra information passed along with the Pattern to allow the GC to be transformed idependantly of the shape it is trying to fill.
I hope that explanation was clear... My current solution doesn't use "createResourcePatternPaint()" at all (nor does it set a background pattern). Instead I hacked up SwtGraphicsEnvironmentAdapter's "setBackgroundPatternPaint()" method so it draws the tiled pattern directly through a call to "CwtSwtGraphicsContext"'s drawImage() method (with some transformations and cropping applied to the repeated images so they fit in the perscribed bounding box).
Anyway, thanks again for a very useful library. I should probably get back to programming now...
You might have guessed: what you describe is exactly why I didn't bother to implement it in the first place ;-)
Hello again :)
I appreciate your work and this library, it renders almost everything right, but I get grey-box images in some pdf files. I've read the previous posts and I've no idea whether it concerns this issue. If you willing to look at the pdf, I'd be happy.
Are your problem PDFs produced by ghostscript or one of its relatives? If so it's very probable that your grey boxes are the same as davidcw3's grey boxes. In fact It's almost always patterns or shadings in the PDF that cause this. I don't think they will be implemented (by us) in the forseeable future.
If you want to make sure, you can tell me where I can grab your PDF, and I'll have a look.
PDF produced by pdfTex.
Cut out one page: PDF
AFAIK, pdfTeX uses Ghostscript to actually produce the PDF.
All of your grey boxes are radial shadings. Not implemented, sorry.