Transcoders have a problem with headless mode. The reason is they invoke Toolkit.getDefaultToolkit().getScreenResolution() that throws java.awt.HeadlessException (a RuntimeException) which then trips up the application. Calls to the above method must catch the exception and assign a default screen resolution, 100 DPI, for instance. I guess a serious solution would take a parameter. The following code contains such calls: transcoder/ToSVGAbstractTranscoder.java transcoder/wmf/tosvg/AbstractWMFReader.java transcoder/wmf/tosvg/WMFPainter.java Running transcoders in headless mode is very common.
i work on a fix for the transcoder-functionality that takes care of headless environments and accepts a user-provided resolution.
(In reply to comment #1) > i work on a fix for the transcoder-functionality that takes care of headless > environments and accepts a user-provided resolution. > I have a patch available, if you are interested. Should be able to send it before end of Week-end.
*** Bug 43022 has been marked as a duplicate of this bug. ***
Created attachment 21029 [details] fix the problem in WMF transcoders
(In reply to comment #4) > Created an attachment (id=21029) [edit] > fix the problem in WMF transcoders > This should be fixed now
(In reply to comment #5) > (In reply to comment #4) > > Created an attachment (id=21029) [edit] [edit] > > fix the problem in WMF transcoders > > > This should be fixed now > It also accepts a new hint for user-provided resolution. If environment is headless, a fixed default resolution is assumed, else the default resolution is the screen resolution.
Hakan, can you confirm this solves the issue?
(In reply to comment #7) > Hakan, can you confirm this solves the issue? Crazy, but I'm swamped by another project, can't do a proper verification now. Really sorry about this unhelpful attitude. I've read the patch though, it seems totally relevant and to solve the issue with a margin.
I can at least confirm that this patch works for me, and it's nice to have a way to override the resolution (my original code to work around this had the DPI hard-coded to 100dpi, so I will probably use this functionality to keep it at 100dpi.)
*** Bug 47277 has been marked as a duplicate of this bug. ***
Created attachment 24629 [details] Patch v1.1 I guess the original patch also solves a (somehow unrelated) bug in "getViewportHeightInch" ("AbstractWMFReader.java"): resolution was missing there. The updated patch also fixes an issue in "getViewportWidthInch" (same file), as the resolution was missing there (incoherency with "getViewportHeightInch" above). Or perhaps I'm missing something... ;-) The patch was updated to the latest trunk revision (820114, as of this writing). I've also included a bunch of whitespace fixes in the modified source files, which makes the patch slightly harder to read -- sorry...
Fixed bug properties to reflect patch being updated to trunk and also added the usual flags to highlight the fact that a patch is available. :-)
It would be nice if someone could commit this patch or otherwise fix this problem, which causes the testWMF() test cases in FOP's org.apache.fop.image.loader.batik.Image*TestCase to fail when java.awt.headless is true. The problem code is found in AbstractWMFReader as follows: public abstract class AbstractWMFReader { // todo should be able to run in headless environment - as is written, will throw exception during init public static final float PIXEL_PER_INCH = Toolkit.getDefaultToolkit().getScreenResolution(); public static final float MM_PER_PIXEL = 25.4f / Toolkit.getDefaultToolkit().getScreenResolution(); ... } The calls to getScreenResolution() throw a HeadlessException. Regards, Glenn
(In reply to comment #13) > It would be nice if someone could commit this patch or otherwise fix this > problem, which causes the testWMF() test cases in FOP's > org.apache.fop.image.loader.batik.Image*TestCase to fail when java.awt.headless > is true. Glen, are you able to confirm the attached patch fixes the bug in your current test environment? It does touch that code portion and should fix it, in addition to allow configuration of resolution. > Regards, > Glenn Thanks, Helder
I guess we should get this into 1.8 release (see bug 50045). The feature is quite interesting for server-side processing, and a patch is already available: a help request is underway in order to confirm everything is fine (if anyone is able to, please provide the needed information or the steps required in order to confirm this).
(In reply to comment #14) > Glen, are you able to confirm the attached patch fixes the bug in your current > test environment? Ping! This can be "easily" tested locally (in a system with graphics adapted using a command line switch "java -Djava.awt.headless=true [...]" [1]. Help, anyone? [1] http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/
I applied the patch, built batik-all.jar, inserted it into the fop lib directory, and ran fop's junit tests in a graphics environment. I got no errors. Then I ran fop's junit tests in headless mode. I got one error, which is the same error I get without the patch. This indicates the patch did not correct the piece of code that uses a display in fop's junit tests. The offending method that calls HeadlessGraphicsEnvironment.getDefaultScreenDevice is a method in xmlgraphics-commons, java2d.ps.PSGraphics2D.getDeviceConfiguration. Maybe fop's headless junit test problem is not a batik problem, but a XGC problem. [junit] No X11 DISPLAY variable was set, but this program performed an operation which requires it. [junit] java.awt.HeadlessException: [junit] No X11 DISPLAY variable was set, but this program performed an operation which requires it. [junit] at sun.java2d.HeadlessGraphicsEnvironment.getDefaultScreenDevice(HeadlessGraphicsEnvironment.java:82) [junit] at org.apache.xmlgraphics.java2d.ps.PSGraphics2D.getDeviceConfiguration(PSGraphics2D.java:824) [junit] at org.apache.batik.ext.awt.image.GraphicsUtil.getDestination(Unknown Source) [junit] at org.apache.batik.ext.awt.image.GraphicsUtil.getDestinationColorModel(Unknown Source) [junit] at org.apache.batik.ext.awt.image.GraphicsUtil.drawImage(Unknown Source) [junit] at org.apache.batik.ext.awt.image.GraphicsUtil.drawImage(Unknown Source) [junit] at org.apache.batik.ext.awt.image.renderable.PadRable8Bit.paintRable(Unknown Source) [junit] at org.apache.batik.ext.awt.image.GraphicsUtil.drawImage(Unknown Source) [junit] at org.apache.batik.ext.awt.image.renderable.PadRable8Bit.paintRable(Unknown Source) [junit] at org.apache.batik.ext.awt.image.GraphicsUtil.drawImage(Unknown Source) [junit] at org.apache.batik.ext.awt.image.renderable.FilterChainRable8Bit.paintRable(Unknown Source) [junit] at org.apache.batik.ext.awt.image.GraphicsUtil.drawImage(Unknown Source) [junit] at org.apache.batik.gvt.AbstractGraphicsNode.paint(Unknown Source) [junit] at org.apache.batik.gvt.CompositeGraphicsNode.primitivePaint(Unknown Source) [junit] at org.apache.batik.gvt.AbstractGraphicsNode.paint(Unknown Source) [junit] at org.apache.batik.gvt.CompositeGraphicsNode.primitivePaint(Unknown Source) [junit] at org.apache.batik.gvt.AbstractGraphicsNode.paint(Unknown Source) [junit] at org.apache.batik.gvt.CompositeGraphicsNode.primitivePaint(Unknown Source) [junit] at org.apache.batik.gvt.CanvasGraphicsNode.primitivePaint(Unknown Source) [junit] at org.apache.batik.gvt.AbstractGraphicsNode.paint(Unknown Source) [junit] at org.apache.batik.gvt.CompositeGraphicsNode.primitivePaint(Unknown Source) [junit] at org.apache.batik.gvt.AbstractGraphicsNode.paint(Unknown Source) [junit] at org.apache.fop.render.ps.AbstractPSTranscoder.transcode(AbstractPSTranscoder.java:154) [junit] at org.apache.batik.transcoder.XMLAbstractTranscoder.transcode(Unknown Source) [junit] at org.apache.batik.transcoder.SVGAbstractTranscoder.transcode(Unknown Source) [junit] at org.apache.fop.AbstractBasicTranscoderTestCase.testGenericPDFTranscoder(AbstractBasicTranscoderTestCase.java:70)
I made an error in the above comment. The patch does remove 5 errors in fop's junit tests in headless mode. All 5 errors occur with both batik-all-1.7.jar and batik-all-1.8pre.jar in fop's lib directory.
(In reply to comment #18) > I made an error in the above comment. The patch does remove 5 errors in fop's > junit tests in headless mode. All 5 errors occur with both batik-all-1.7.jar > and batik-all-1.8pre.jar in fop's lib directory. Great! :-) Does apparently mean that the patch should definitely be applied. Could you please just confirm that there are no more known errors related with Batik with the patch applied? (I was mostly curious to known whether the patch could even be further improved.) Thanks! ;-)
Whoops, apparently I've recently fixed this problem with revision http://svn.apache.org/viewvc?rev=1076146&view=rev without noticing the open Bugzilla ticket. I seem to have solved this in a slightly different way than suggested. Please reopen if you find that my solution is suboptimal.