Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 4.3.1
-
Component/s: Core/Parsing
-
Labels:None
-
Environment:Win7, PDF 1.5
Description
we got a problem rendering and viewing pdfs including jpeg images.
We created a PDF using aspose. The standard pdf viewers (acroread, preview, ... )
perfectly display and print the file. Unfortunately, icepdf does not.
The box including the image remains empty.
Find the pdf entailed.
Best
Johannes
Activity
- All
- Comments
- History
- Activity
- Remote Attachments
- Subversion
Pushing to 4.3.3 as there are few more tiling bugs that might be related.
Recent work to PDF-448 has the tile being painted but the tile isn't being scaled correctly. After further investigation the paint code
af.setToScale(matrix.getScaleX(), matrix.getScaleY());
af.setToShear(matrix.getShearX(), matrix.getShearY());
actually doesn't set the scale, the shear call actually applies an identity matrix with the shear x/y values set..
Still a some more things to figure out.
Progress has been made on this file the first test file in that the image tile is show but is currently not in the correct location. Further work is needed to figure out what is going wrong how the tile is painted.
Fixed as part of PDF-710 tiling scale fix. Marking as fixed.
Hi,
unfortunately the problem is NOT fixed.
Still standard pdf viewers like Adobe, Foxit, preview... display and print the file. Icepdf does not. Neither in the ICEpdf Viewer nor in print.
I attached a new pdf (error.pdf) with images and a screenshot showing the output in ICEpdf Viewer (viewer.jpeg).
Best
Johannes
Hi Johannes;
Please contact support@icesoft.com and they will be able to get you the download link to 5.0.6_P02 which renders this PDF correctly.
Patrick
The correct email address for support is product.support@icesoft.com
I can't seen a problem with issue2, using the latest release 4.3.1 as well as 4.2.3.
However I can reproduce the missing image in icepdf-issue.pdf . The root of the problem is actually an issue with how we are handling tiling pattern fill. The image is part of an tilling content stream of type 3 which for some reason doesn't have a case for it in our contentParser. My guess is that this is the first example we have of this type of pattern.
The image is encoding correctly, so I don't see a problem implementing the code needed to display the tiling pattern and thus the image in question.