We Keep Coding

Replacement for COSName.DOCMDP in PDFBox 2.0.4

I'm testing the example codes from this page:
https://svn.apache.org/viewvc/pdfbox/trunk/examples/src/main/java/org/apache/pdfbox/examples/signature/
But inside the file CreateSignatureBase.java, exactly in the functions getMDPPermission and setMDPPermission, it calls a property that doesn't exist anymore: COSName.DOCMDP. I perused the Pdfbox page and its migration guide and it doesn't mention this property and how to replace it. I also looked into the PDfbox source code (exactly the file COSName.java) and It doesn't have that property, despite this file:
https://svn.apache.org/viewvc/pdfbox/branches/2.0/pdfbox/src/main/java/org/apache/pdfbox/cos/COSName.java?view=markup does have it.
I checked both pdfbox-2.0.4.jar and pdfbox-app-2.0.4.jar adding them to the Netbeans project where I'm testing the java files from the pdfbox examples. None of them have the property COSName.DOCMDP in the COSName class.
Both jars and the pdfbox sourcecode are downloaded from here:
https://pdfbox.apache.org/download.cgi#20x
How can I replace the property COSName.DOCMDP in the CreateSignatureBase class? Am I getting the right jars?

It will appear in 2.1.0 version:
https://issues.apache.org/jira/browse/PDFBOX-3017
https://issues.apache.org/jira/browse/PDFBOX-3699
https://svn.apache.org/viewvc/pdfbox/trunk/pdfbox/src/main/java/org/apache/pdfbox/cos/COSName.java?annotate=1786065
If you need it for testing purposes, you may download it's SNAPSHOT version from https://repository.apache.org/content/groups/snapshots/org/apache/pdfbox/pdfbox/
Or, you may see this example in current stable version - just download 2.0.4 jar and browse examples.

How to fix: image reader not registered error in dcm4che plugin?

I am getting the following error when I try to extract images from DICOM file. It works for some files but not all. How to solve this? I am using dcm4che library for the conversion. The jar, dll, so files are added to lib.
Image Reader: com.sun.media.imageioimpl.plugins.jpeg.CLibJPEGImageReader not reg
istered. Stacktrace follows:
java.lang.RuntimeException: Image Reader: com.sun.media.imageioimpl.plugins.jpeg
.CLibJPEGImageReader not registered
at org.dcm4che.imageio.codec.ImageReaderFactory.getImageReader(ImageRead
erFactory.java:205)
Library version:
dcm4che-core-3.2.1
dcm4che-image-3.2.1
dcm4che-imageio-3.2.1
dcm4che-imageio-rle-3.2.1
dcm4che-tool-dcm2jpg-3.2.1
jai_imageio-1.2-pre-dr-b04

You have to have jai installed into the jre with the correct native components for the os/architecture you are using.
This doc has instructions for dcm4chee, but the concepts are the same even if you are only using pieces.

Apache FOP in a Java Applet - No ImagePreloader found for data

I'm looking at an issue in a mature commercial product.
In a nutshell, we are using part of the Apache POI library to read in a Word .DOC or .DOCX file, and convert it into XSL-FO so that we can do token replacements. We then use FOP – embedded into the Java program - to convert the FO data into a PDF for printing. The catch is, all this is being done on the client inside a Java applet running inside Internet Explorer.
Originally we were using FOP 0.93, which worked reasonably well. However, it was not able to utilise the fonts inside the DOC file when generating the PDF and would map everything to Times, which one of the customers did not like. In theory it could be made to work by adding some kind of font metrics data, but that would require a relatively complex definition for every font it was likely to encounter and we can’t predict what the client is liable to use outside of the MS core fonts set.
To fix this, FOP was upgraded to 1.0, which added support for autodetecting the fonts from the operating system. This worked, but we noticed that the image processing had stopped working and the letterheads had disappeared.
What appears to have happened is that the image loader inside FOP was rewritten at some point between 0.93 and 0.95 so that instead of using Jimi and JAI it now uses ImageIO. The earlier implementation worked fine, but the new code doesn’t like being run as an applet.
Images are embedded in URIs in the FO data so we get an error like this:
2014-09-30 17:00:10,607 ERROR [org.apache.fop.apps.FOUserAgent] Image not available. URI:
data:image/jpeg;base64,iVBORw0KGgoAAAANSUhEUgAAALQAAABSCAIAAABysmn6AAA...
...ggg==. Reason: org.apache.xmlgraphics.image.loader.ImageException: The file format is not supported. No ImagePreloader found for data:image/jpeg;base64,iVBORw0KGgoAAAANSUhEUgAAALQAAABSCAIAAABysmn6AAAA...
When run through a test harness, the correct output is generated, but when run as an applet inside the browser we get the above error which makes me suspect that the browser applet security is jamming the ImageIO plugin loader somehow.
The guts of the FOP transformation, i.e. the bit which is triggering the error is this:
// Step 4: Setup JAXP using identity transformer
TransformerFactory factory = TransformerFactory.newInstance();
Transformer transformer = factory.newTransformer(); // identity transformer
transformer.transform(src, res);
...which is all being run inside a PrivilegedAction block since in FOP 1.0 it needed file I/O access to manage the font cache.
Running the standalone FOP 0.93 and 1.0 programs under linux and using strace shows that it is writing out temporary files for the image data, but both 0.93 and 1.0 do similar things, so it shouldn’t be that by itself, especially since it should have permission to create temp files already.
I've tried different versions of the JRE since some builds a few years back apparently had security issues with the ImageIO library, but to no avail.
Any ideas?
Thanks,

In case anyone else has something similar, this turned out to be caused by the way the project was being built in Maven.
Fop 1.0 and above use the xml-graphics-commons library to facilitate the image rendering. As mentioned in the question, this uses a plugin registry which is configured using the following files inside the JAR:
META-INF/services/org.apache.xmlgraphics.image.loader.spi.ImageConverter
META-INF/services/org.apache.xmlgraphics.image.loader.spi.ImageLoaderFactory
META-INF/services/org.apache.xmlgraphics.image.loader.spi.ImagePreloader
...each of these contains a list of the image decoders which will be supported.
The problem is that xml-graphics-common ships these files with a sensible list of defaults, while FOP also has a conflicting set of defaults, which for some weird reason disable all of the image decoders, and that one was taking priority.
To solve the problem, I made sure that my maven pom.xml file imported xml-graphics-common before FOP, so that its defaults took precedence, and at that point everything sprang to life.
I am still not sure why the code was working correctly as a standalone test program, but I suspect it was the way the classpath was being handled being different to it running in plugin mode.

In my case the plugin registry loaded ImagePreloaders from both the plugin files and mixed them together. Yet the error still appeared. I was inserting an SVG file into a PDF file. The root cause was incorrect version of org.apache.xmlgraphics:batik-svg-dom. The 1.7 version was required by the org.apache.xmlgraphics:fop:1.1, however, the 1.8 version was on the classpath.
There is a key difference between the two versions: the org.apache.fop.image.loader.batik.PreloaderSVG class needs org.apache.batik.dom.svg.SAXSVGDocumentFactory from the version 1.7 on the classpath. If it gets org.apache.batik.anim.dom.SAXSVGDocumentFactory from the 1.8 version it does not work as expected.
This SO question: Where has org.apache.batik.dom.svg.SVGDOMImplementation gone? was helpful to me when resolving this issue.

Just been struggling with this one. If you're using the maven-shade-plugin to create an uber jar, use the ServicesResourceTransformer to merge all the services configuration:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-shade-plugin</artifactId>
<version>2.2</version>
<executions>
<execution>
<!-- snip -->
<configuration>
<transformers>
<!-- snip -->
<transformer implementation="org.apache.maven.plugins.shade.resource.ServicesResourceTransformer"/>
</transformers>
</configuration>
</execution>
</executions>
</plugin>

thanks for the post!
I can assert that this also works by changing ordering in Eclipse!
in my case, under Windows it was working fine, but same JAR file in RHEL raised an error

How to downgrade arbitrary PDF file to version PDF-1.2?

I have some user generated PDF files. Typically the files are be generated with Word, but they could be just a about any kind of valid PDF file. I'd like convert the file to version PDF-1.2 if they have higher version number. The features available only in higher version (like multimedia) should be removed and the result should be still reasonably reasonable and readable.
How to do this programmatically, without interactive tools such as Adobe Acrobat? Preferably with Java and iText-library, but I would be interested in other solutions also.
One way would be to generate a bunch of images from original PDF and then package them as a PDF-1.2 file, but is the a more elegant way?

Try the commandline below. It uses Ghostscript to re-distill the PDF. Use Ghostscript version 8.71 or newer: 9.00. (The wrongly up-voted answer above advicing to "set PDF version in iText using setPdfVersion()" will NOT work -- it only re-labels the PDF, which will only be mis-leading...)
gswin32c.exe ^
-o output-v1.2.pdf ^
-sDEVICE=pdfwrite ^
-dPDFSETTINGS=/ebook ^
-dCompatibilityLevel=1.2 ^
input-v1.6.pdf

The easiest is to reprint it through Ghostscript.

You can set the PDF version in iText using setPdfVersion() however downgrading won't work out of the box I think. You could use PdfCopy and write your pdfs to a new one with the version 1.2 and strip out all none 1.2 objects. Or convert them to version 1.2 objects (which you will have to do yourself I think, not sure however)

Incompatible magic value 1008813135

I am writing a Java applet and embedding it in a web page.
It used to run Mac and Windows in different browsers without problem.
I was using NetBeans on the Mac to build the .jar file the applet used.
For some reason or another I decided to load the project on the Windows' NetBeans - I started getting the following error on the Windows machine when accessing the web page from any browser:
java.lang.ClassFormatError: Incompatible magic value 1008813135 in class file
Fearing that it must have been my decision to open the project on Windows that caused this error - I tried to build from the Mac's NetBeans - but the error persisted.
I started a while new project on the Mac and imported the existing source code: still same problem.
I was doing some reading about this error and it seems that the magic number expected is 0xCAFEBABE in hex which is 3405691582 in decimal, not 1008813135. So it looks like the Mac version of Java doesn't produce this file header any more? Hoe can that be? I didn't do any updates or anything.

Yes, 0xCAFEBABE is the usual first 4 bytes of a Java file.
1008813135 is <!DO in Latin encoding, which is, in all probability, the start of <!DOCTYPE....
It is therefore likely the start of a 404 error, or some other error page.

I have not experienced this problem, but Googling this error yields several possible solutions:
forum.sun.com - Java Applet Development - Incompatible magic value 1008813135 in class file MyApplet
Thanks God the problem is solved.
Its the Java cache, so the solution go to Java Control Panel, "General" tab, and under "Temporary Internet Files" click "Settings", then click "Delete Files". Try using the applet again.
"Incompatible magic value 1008813135" Error?
The problem is now solved: I found out that the website host I was using didn't support .jar files at all. I mass-uploaded the files with my ftp program and didn't notice that it ignored the .jar files completely.
Errors on java initialization
Alright, so it was an apache configuration issue, removed this line from my httpd.conf file:
# DefaultType application/x-httpd-php
Fixed the issue.

If you are using Spring security or some sort of custom Servlet Filters, make sure, that the archive or codebase location is in "permitAll" access. This was to problem in my case

I was facing the same problem.The reason in my case was all dependency library that Applet uses was not signed and also applet not able to locate them.
So i Have added all the dependent library along with main applet in jsp file like below :
app.archive = '/esense/resources/lib/Applet.jar, /esense/resources/lib/jasypt-1.7.jar, /esense/resources/lib/mysql-connector-java-5.1.30.jar, /esense/resources/lib/runtime-api-1.0.jar';
I have also signed all the jar.
Hope this may work in your case.

The incompatible magic number is the first four bytes of a html file that has some error message in it, probably a message that the file isn't found.
I encountered this phenomenon when I didn't take case sensitivity into account in the codebase element of the applet tag. Things worked well on Windows, but the internet server I was using was running UNIX where filename case sensitivity is important. Making the case of all file and directory names in the code and codebase elements solved the problem.

I just clicked on maven->update project->include snapshot release in my spring boot and it worked.