Thomas DeWeese wrote:
Peter Becker wrote:
Hi all,
after someone reported having troubles with my little XWeb program (http://xweb.sf.net) and rendering SVGs on a 1.4.2 JDK on Linux, I tried upgrading to Batik 1.5. This seems to fix the problem with empty results which were reported, but unfortunately the looks of some buttons rendered for one of my sites (http://tockit.sf.net) change quite a bit.
Since I added the Batik version to XWeb before I figured out that one should keep track of version numbers I can't tell the version of Batik I used before -- according to CVS it must be about 17 month old. Here are some comparisons of PNGs rendered with that Batik, with Batik 1.5 and the SVG used to create them (kind of -- it is what XWeb would generate). Total file size is less than 11kb.
Example one: - http://www.itee.uq.edu.au/~pbecker/batik/overview_old.png - http://www.itee.uq.edu.au/~pbecker/batik/overview_1_5.png - http://www.itee.uq.edu.au/~pbecker/batik/overview.svg
This one looks pretty much the same to the old version in Adobe's viewer.
Example two: - http://www.itee.uq.edu.au/~pbecker/batik/docco_old.png - http://www.itee.uq.edu.au/~pbecker/batik/docco_1_5.png - http://www.itee.uq.edu.au/~pbecker/batik/docco.svg
This SVG actually could be better -- at least Adobe's viewer doesn't really like it.
Any explanation for this problem? Anything I can do to avoid it? If it is a bug -- any hints were to dig in the code?
The problem is caused by our switching to use drawGlyphVector in many
cases instead of always drawing raw shapes. Fortunately you can override
this by saying text-rendering="GeometricPrecision". This should give
you the same rendering as before. You might also try 'optimizeLegability"
which will shut off anti-aliasing of the text - some people prefer it.
I don't understand this bit. You changed the code somehow and now the text looks quite different. Is this a feature? Or a bug?
Hi Peter,
One man's feature is another man's bug. It is intentional that we switched to use drawGlyphVector over rendering raw shapes. This has a number of advantages ranging from speed to the ability to render legible text without anti-aliasing. I will however freely admit that the text does look different from before, in some cases quite at bit different.
Is there any specification how the text should look like? The thing I found is this entry:
http://www.w3.org/TR/SVG11/painting.html#TextRenderingProperty
which says that the default setting "auto" ... "Indicates that the user agent shall make appropriate tradeoffs to balance speed, legibility and geometric precision, but with legibility given more importance than speed and geometric precision."
So I assume that you changed the tradeoff policy between the Batik versions. But I must say that I disagree with the choice -- for the purpose of offline-rendering speed doesn't really bother me that much. Is there any way that I can set the behaviour for "auto" from the Java side of things? I want my Java program to prefer precision over speed for any SVG given to it.
This would be a nice feature but currently there is no magic switch to set the default set of hints that Batik uses for rendering. Contributions are always welcome!
You can set the text-rendering property on the root of the document tree before rendering and because of CSS this will then effect all text nodes (unless someone overrides it).
BTW: it still seems the gamma problem I have is still around. If you look at http://tockit.sf.net with Internet Explorer you will notice that the navigation PNGs are of a slightly different colour than the surrounding bits and pieces. I tracked that down once to the gamma value in the PNGs which seems to be ignored by most software but IE (e.g. the site looks good in Mozilla). Is there any new insight on how to avoid that problem?
From what you have said so far I would say it is a bug in what ever
other software you used to generate PNG files that they do not include
a gama chunk. You could hack Batik so it doesn't generate one but I
don't think this would be the right approach to take.
Hmmm... look at this page in IE: http://www.itee.uq.edu.au/~pbecker/batik/testColor.html
This is the Batik-rendered PNG on top of HTML background with exactly the same RGB values. And it is clearly rendered differently while Mozilla produces the same color. As does Adobe's viewer from the SVG.
If you think that Batik should remove the Gama chunk from the PNG files that it creates than I strongly disagree, quoting from the PNG specification:
If the encoder does not know the image's gamma value,
it should not write a gAMA chunk; the absence of a gAMA
chunk indicates that the gamma is unknown.In this case we know exactly what the gAMA is (all SVG output is in standard sRGB colorspace with a gama of 2.2) so we provide that information as the PNG standard says we should.
There was a bug reported that Batik produces a gamma value that is off by one code value. I put in the code to fix this but didn't 'turn it on' because it causes all our test images to fail compairison and it was a bad time to do that. However you might try turning that on, xml-batik/sources/org/apache/batik/ext/awt/image/codec/PNGImageEncoder.java line 556. This should not produce a visably different result, but perhaps it does in IE. I would be interested in knowing if this fixes it.
There is also a gamma transcoding hint that you could try using. See batik.transcoder.image.PNGTranscoder line 214. This is not currently exposed from the application.
Aside from those options if you actually want to remove the generation of Gamma chunks for Batik you will have to hack it yourself (it is not something I will spend time on). If done well (i.e. made a comand line parameter etc, and you are willing to sign a contributors agreement) it would probably be accepted into Batik.
According to IrfanView the color rendered by IE on screen is (76,106,148) instead of the (90,115,156) it should be. I don't have any of these problems with other PNGs -- at least I didn't notice although I tend to be picky about matching up colors.
But let's not play the blame game -- I don't care whose fault it is, I just want the results to be good. At the moment I am not happy with the
looks of my website in IE -- which I rarely see myself but unfortunately IE is still the most common browser, so I have to accomodate for that. It seems to be somehow the combination of Batik's rendering of the SVG into PNG with IE's rendering of the PNG onto the screen that causes the problem -- most programs I tried display the PNG as I want it.
I'm not playing the blame game - you wanted suggestions to fix the look of your site and I gave you two - have the rest of your software generate Gamma chucks (as they should) or you can hack Batik. I've given you some additional options above.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
