ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf

Hello;

The image scaling method was changed in 4.3.x as the previous version could in some cases changed the images colour model. Image scaling can be turned off a couple different ways and will likely be turned off by default in future release.

If you have access the start-up script you can use the system property
-Dorg.icepdf.core.scaleImages=false

If not you can set the system property via the utils class but keep in mind it has to be set before a document is loaded.

Defs.setSystemProperty("org.icepdf.core.scaleImages", "true");

I can reproduce the problem locally. The error stems from an issue decoding a jbig2 image. I'll have to take much closer look to see why the jbig2 parser is chocking on this particular image stream.

Is there any chance you could post the orginal file before PdfCompressor touches it?

I've created http://jira.icefaces.org/browse/PDF-387 for this issue. .

1) IcePDF is a class library / developer tool?
Yes, ICEpdf is a SDK that allows a developer to integrate ICEpdf rendering core into a larger application. There are other advanced API features such as search, text highlighting, and annotation modification available in the SDK.

2) Are there any third party applications built on IcePDF that are sold / supported by other companies?
We are not aware of any third party application build on ICEpdf that sold/supported by other companies.

3) I am trying to help my client decide between either a client or web based solution, and wondered if anyone can point me towards existing docs trading off the two approaches, in particular:

a) Cross browser portability
The Java client will be problematic on operating system that don’t have full Oracle j2se support . A server side solution would be an option for mobile devices. There is an ICEfaces/JSF example in the bundle that uses an underlying Servlet to render page content to the client which might be of interest.
b) Security concerns
A server base solution is indeed secure if you are worried about the securing the PDF files source. However it is still possible to capture the images sent back from the server, it can be made more difficult but ultimately is still possible. If the content rather than the actual source is more important to secure the client approach has some advantages. Limiting printing and content extraction is possible through standard PDF security but screen capture is always a problem.
Some ICEpdf clients have implemented their own security mechanism for document transfer but I’m not aware of the specifics. In general using a public key encryption can be quite secure. It’s possible to obfuscate the client jars which can make reverse engineering your security method very difficult. You might want to check the PDF specification for more information on document permissions available in Adobe Standard Encryption.

c) Printing
Printing from the browser is controlled by the browser so in general it’s not the best way to go about printing a PDF. Multi-page management and print quality can be difficult to control from a browser. In both the browser and Java client screen captures will always be a problem. The number of pages printed could be controlled in a number of different ways other than a properties file. Some clients have used a DataBase query to grab a PDF file and any secondary meta data needed to load the file.

Is there any chance you could prep a test file that exhibits the loading problem.

Text annotations and highlight annotations are scheduled for the next major release. Is there any specific annotation type you're interested in?

ICEpdf 4.3.1 has been release which addresses the thumbnail issue.

Sorry for the inconvenience. I'll make sure a patch release get out early next week.

Are you building the Viewer jar from source?

The Trial version is pretty heavily obfuscated and the signature for Page.getThumbnail() is different then reported in the stack trace. If I where to take a guess it would be that you have the icepdf-viewer.jar from the 4.3.0 pro bundle on the class path instead of the trial version of the same jar.

So this is pretty embarrassing on my part. To correct the problem you'll need to update the ViewApplet class so that an instance of a properties manager is passed into to the SwingViewBuilder.

Code:

PropertiesManager properties =
                 new PropertiesManager(System.getProperties(),
                         ResourceBundle.getBundle(PropertiesManager.DEFAULT_MESSAGE_BUNDLE));
 
 SwingViewBuilder factory = new SwingViewBuilder(controller,
                 properties);

A user has already created http://jira.icefaces.org/browse/PDF-382 to capture this issue. I'll make sure this get cleaned up on the trunk.

Thanks and thanks, all fixed.

ICEpdf v4.3 is now available for download, SVN repository checkout, or via the Maven2 repository (jars only).

ICEpdf v4.3 is a certified production release that introduces important new features such as thumbnail utility pane, Adobe Standard Security Revision 4 and 5, improved soft mask image support, colour conversion and rendering of CID fonts. This release also includes more than 30 bug-fixes and enhancements.

Refer to the Release Notes for full details.

All questions, comments, or general discussion specific to ICEpdf 4.3 should be made in the ICEpdf forum.

For information on commercial support, professional services, and training, please visit http://support.icepdf.org.

ICEpdf v4.3 is now available for download, SVN repository checkout, or via the Maven2 repository (jars only).

ICEpdf v4.3 is a certified production release that introduces important new features such as thumbnail utility pane, Adobe Standard Security Revision 4 and 5, improved soft mask image support, colour conversion and rendering of CID fonts. This release also includes more than 30 bug-fixes and enhancements.

Refer to the Release Notes for full details.

All questions, comments, or general discussion specific to ICEpdf 4.3 should be made in the ICEpdf forum.

For information on commercial support, professional services, and training, please visit http://support.icepdf.org.

Created http://jira.icefaces.org/browse/PDF-380, so the enhancement request isn't lost.

Early last year we we had a client with a similar problem. I spend a little time looking into it and it appeared to be a JDK issue. Almost like a value change issue. I don't have much more information then that.

There appears to be something wrong with the xref tables data offsets. No easy fix for this problem at this time, sorry. The bug PDF-336 captures this issue.