[... text rendering default policy ...]
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!
Any hint how a proper feature for Batik would be implemented? Some Java property file given as command line option, mapping the relevant properties from above document to their defaults?
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).
I could hack the DOM before putting it into Batik. But I'll have a look at Batik and finding a proper solution first. Might take a while until I get there, though.
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.
Somehow it all sounds like a big hack to me, but I do understand your line of thought. Which doesn't fix my problem, so I'll have a look at "fixing" Batik by rendering "broken" PNGs. Terms in quotes depend on the point of view :-) I think the ideal situation would be providing an override to either set a particular gAMA (whyever you want that) or none (reading 0.0 as "don't use" seems appropriate here). Might be another candidate for a properties file entry.
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.
Sounds doable. Otherwise I always have the option of using either a hacked .class or .jar file ;-) But I'll have a look at finding a proper solution.
At the moment I am on a slow connection, but I'll grab the Batik source soon. I suspect CVS is the way to go, isn't it?
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.
The first one is not really always an option -- sometimes I want PNGs to match table backgrounds etc. I can't get IE to render those in sRGB, so that won't do for me :-( But hacking Batik is something doable :-)
Thanks, Peter
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
