Bug 42408 - [PATCH] Headless problem in transcoders
[PATCH] Headless problem in transcoders
Status: RESOLVED FIXED
Product: Batik - Now in Jira
Classification: Unclassified
Component: SVG Rasterizer
1.8
Other All
: P2 normal
: ---
Assigned To: Batik Developer's Mailing list
: PatchAvailable
: 43022 47277 (view as bug list)
Depends on:
Blocks: 50045
  Show dependency tree
 
Reported: 2007-05-14 08:40 UTC by Hakan Soderstrom
Modified: 2011-03-22 10:24 UTC (History)
4 users (show)



Attachments
fix the problem in WMF transcoders (13.36 KB, patch)
2007-10-23 15:49 UTC, Hervé Girod
Details | Diff
Patch v1.1 (17.43 KB, patch)
2009-11-29 04:03 UTC, Helder Magalhães
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Hakan Soderstrom 2007-05-14 08:40:52 UTC
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.
Comment 1 info 2007-05-15 00:47:48 UTC
i work on a fix for the transcoder-functionality that takes care of headless
environments and accepts a user-provided resolution.
Comment 2 Hervé Girod 2007-08-23 02:44:15 UTC
(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.
Comment 3 Hervé Girod 2007-08-23 02:45:11 UTC
*** Bug 43022 has been marked as a duplicate of this bug. ***
Comment 4 Hervé Girod 2007-10-23 15:49:36 UTC
Created attachment 21029 [details]
fix the problem in WMF transcoders
Comment 5 Hervé Girod 2007-10-23 15:49:57 UTC
(In reply to comment #4)
> Created an attachment (id=21029) [edit]
> fix the problem in WMF transcoders
> 
This should be fixed now
Comment 6 Hervé Girod 2007-10-25 13:35:50 UTC
(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. 
Comment 7 Cameron McCormack 2007-12-31 14:55:20 UTC
Hakan, can you confirm this solves the issue?
Comment 8 Hakan Soderstrom 2008-01-14 02:55:39 UTC
(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.

Comment 9 Trejkaz (pen name) 2008-01-16 17:02:44 UTC
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.)
Comment 10 Helder Magalhães 2009-11-29 03:31:54 UTC
*** Bug 47277 has been marked as a duplicate of this bug. ***
Comment 11 Helder Magalhães 2009-11-29 04:03:16 UTC
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...
Comment 12 Helder Magalhães 2009-11-29 04:05:50 UTC
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. :-)
Comment 13 Glenn Adams 2010-09-07 05:39:01 UTC
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
Comment 14 Helder Magalhães 2010-09-08 01:49:50 UTC
(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
Comment 15 Helder Magalhães 2010-10-06 09:10:44 UTC
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).
Comment 16 Helder Magalhães 2010-10-30 04:40:23 UTC
(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/
Comment 17 Simon Pepping 2010-11-10 10:08:17 UTC
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)
Comment 18 Simon Pepping 2010-11-17 07:34:36 UTC
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.
Comment 19 Helder Magalhães 2010-11-20 19:06:10 UTC
(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! ;-)
Comment 20 Jeremias Maerki 2011-03-22 10:24:43 UTC
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.