I'm using Ghost4j to render PDFs, but it throws the following sorts of errors sometimes when trying to render documents that were created by MS Word
[main] ERROR org.ghost4j.Ghostscript - GPL Ghostscript 9.18: Some glyphs of the font TimesNewRoman requires a patented True Type interpreter.
According to this thread this may be due to the Ubuntu Ghostscript package leaving out certain fonts. So I compiled the latest Ghostscript (9.22) from source and installed it, and it's now the version that comes up when I use the gs command, but Ghost4j still seems to be using the old 9.18 version.
How can I tell it to use the new version of Ghostscript?
Ghost4j doesn't use the ghostscript installation per se, instead both ghost4j and ghostscript use a library called libgs.so. This library is a dependecy of ghostscript but also comes with an installation called libgs-dev (on Linux).
I am suspecting that somehow Ghost4j uses some leftower version of the library.
So if you are using the latest version of Ubuntu installing libgs-dev should solve the problem, however all current stable versions of Linux default to the 9.18
We solved this problem by manually building that library and symlinking the version we need to the libgs.so file. You can download the compiled dynamically linked version 9.22 of libgs.so here(personal dropbox link) save it under /usr/lib/x86_64-linux-gnu/libgs.so.9.22 and run
ln -fs /usr/lib/x86_64-linux-gnu/libgs.so.9.22
/usr/lib/x86_64-linux-gnu/libgs.so
and, if one does not trust strangers on the internet like one shouldn't here are the instructions for building it yourself:
(tutorial for building gs),
(gs source code).
To make sure everything else is the same we use Ghost4j 1.0.1 and JNA 4.1.0
<dependency>
<groupId>net.java.dev.jna</groupId>
<artifactId>jna</artifactId>
<version>4.1.0</version>
</dependency>
<dependency>
<groupId>org.ghost4j</groupId>
<artifactId>ghost4j</artifactId>
<version>1.0.1</version>
</dependency>
While solving this problem I found this endpoint method to be really usefull:
#RequestMapping(value = "/gs/version", method = GET)
public GhostscriptRevision gsVersion() throws IOException {
return Ghostscript.getRevision();
}
Good luck.
Related
I'm working with a struts 2.3.4.1 and am using the struts2-jasperreports-plugin to display a pre-compiled report. Fonts have been giving me issues, which I found was supposedly fixed in Jasperreports 6 (specifically issues with Calibri). Because I'm on a legacy system running java 6, the last version I can use is 6.2.2. But when I try to display my report, I get java.lang.NoSuchMethodError: net.sf.jasperreports.engine.util.JRLoader.loadObject(Ljava/lang/String;)Ljava/lang/Object;
org.apache.struts2.views.jasperreports.JasperReportsResult.doExecute(JasperReportsResult.java:323), which seems to be a function called by the struts2-jasperreports-plugin that doesn't exist in jasperreports 6+. I've been looking around, but cannot find out if/how to change this behavior and am beginning to think that I need to update the version of my plugin.
Is there a way to change the function called by the plugin, or am I going to need to change the version of struts to get the behavior I expect? Is it possible to write an adapter for a plugin?
After some more troubleshooting, I found https://stackoverflow.com/a/37864625/892327 in which an adapter was made using existing code, which I got from https://web.archive.org/web/20180523111530/http://grepcode.com/file/repo1.maven.org/maven2/net.sf.jasperreports/jasperreports/6.1.0/net/sf/jasperreports/engine/util/JRLoader.java/, and added the missing loadObject(String fileName) function as an adapter for the loadFromFile(String fileName). Which cleared the NoSuchMethodError.
However, the original issue java.lang.ArrayIndexOutOfBoundsException: 0 sun.font.ExtendedTextSourceLabel.createCharinfo(ExtendedTextSourceLabel.java:592 returned, which was "fixed" by changing the version of Java I was running, found at Error generating JasperReport in Development mode.
Because I'm working with a legacy system that runs on Java 6, I've given up since the original issue is JRE based and not a bad Jasperreports library or struts plugin.
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.
I’m trying to convert a version 401 binary dictionary -- a directory called PersonalizationDictionary.en_US.dict -- to human readable .xml.
The command line utility dicttool_aosp in packages/inputmethods/LatinIME/tools/dicttool can do it like so:
dicttool_aosp makedict -s sourcedict.dict -x output.xml
I’m unable to compile the Android Lollipop version of dicttool, since dicttool has native C++ dependencies that don’t play nice with my Mac. Note this line in the NativeLib.mk file of dictool:
HACK: Temporarily disable host tool build on Mac until the build system is ready for C++11.
I am hoping someone with a compatible setup can compile this utility for me using “make dicttool_aosp” from the root of the AOSP source tree. I've spent the past few days looking for compiled versions of it, and while I’ve found many makedict.jar files online, they are too old to support my newer V401 binary dictionary. The main difference between the V401 and older versions is that a V401 is split up into multiple files with extensions like .bigrams, .freq, .header, whereas the older dicts are contained in a single file.
Thank you, please let me know if I can clarify anything!
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
I would need to build one android app from command line. I successfully compiled its jni part, but cannot build Java part. ant prints the following (paths have been removed):
/.../build.xml:69: taskdef class com.android.ant.SetupTask cannot be found
using the classloader AntClassLoader[/path/to/sdk/tools/lib/ant-tasks.jar:/path/to/sdk/tools/lib/manifest-merger.jar:/path/to/sdk/tools/lib/common.jar:/path/to/sdk/tools/lib/guava-13.0.1.ja r:/path/to/sdk/tools/lib/sdklib.jar:/path/to/sdk/tools/lib/layoutlib-api.jar:/path/to/sdk/tools/lib/kxml2-2.3.0.jar:/path/to/sdk/tools/lib/dvlib.jar:/path/to/sdk/tools/lib/bcpkix-jdk15on-1.4 8.jar:/path/to/sdk/tools/lib/commons-compress-1.0.jar:/path/to/sdk/tools/lib/httpclient-4.1.1.jar:/path/to/sdk/tools/lib/httpmime-4.1.jar:/path/to/sdk/tools/lib/bcprov-jdk15on-1.48.jar:/path /to/sdk/tools/lib/httpcore-4.1.jar:/path/to/sdk/tools/lib/commons-logging-1.1.1.jar:/path/to/sdk/tools/lib/commons-codec-1.4.jar]
It seems that SetupTask is inside anttasks.jar, but it is not in my sdk directory. I tried to install all available sdks, tried to add ant-tasks.jar to the class path (it has similar name), but with no success. Is there any way how to install anttasks.jar, or is it replaced by something else? Or is SetupTask obsolete in some way?
I have run:
android update project ...
I tried to find answer by google but with no success for this particular issue (AntClassLoader is not empty, anttasks.jar is missing).
Thanks,
Daniel
Afaik the SetupTask ist obsolete in Android 2.3 and higher. So it seems to me like you're working with an old version of the build.xml. Since Android 2.3 and higher, there is a new template for the build.xml in the directory
your-android-SDK/tools/ant/. You can modify this one according to your needs.
Maybe this link will help you, it pointed me in the right direction:
https://sites.google.com/site/sokolkosta/internal-blog/includingadditionaljavaxpackagesinandroid23
https://stackoverflow.com/a/15719072/1343309
It worked for me.
rm MyProjects/NowRedux/build.xml
android update project --target 8 --path MyProjects/NowRedux