Peter Becker wrote:
the text rendering just won't change, independent of the hints given -- did you commit the change mentioned below or shall I just wait a bit longer?
It is in there, and it does change the rendering.
Oh, you are right -- it does change and it is actually not too bad at all. I was just too much into comparing it with the old one, and it is definetely not the same as that. But once I compared the three I must say that the newest one is the best.
In respect to the idea at the end of using a user stylesheet: that might be an option -- if I could provide the CSS. But I'd like to provide it as String (or similar), not as URI since I'd like to code it into my program as the defaults. I might be able to get some URI into a jar file that I could use, but it would be rather complicated to change the little default setting.
Not really this sort of thing is done all the time. I suggest you
look up how resources are used in Java. This is a relly nice technique.
Hmmm... it needs at least an extra file which logically belongs to one bit of code but has to be added in the jar-packaging process. I'll look into it but I suspect I will have to make some assumptions between code and classpaths -- and that just for changing one default. I'd prefer to set transcoding hints for the corresponding CSS rendering hints that have "auto". Are there more than two?
And wouldn't the user stylesheet override the standard entries in the file's CSS? That wouldn't be what I want, I just want to change the default.
This really depends on how the CSS and user content is written - it
is possible to write a fairly non-intrusive CSS rule to set this.
The thing is that I would prefer not to make any assumptions about the user content. Is that possible?
Can you give me a pointer to the part of the code where the transcoding hint would be used? I can find a bunch of constants in org.apache.batik.css.engine.value.svg.TextRenderingManager but I can't see where they get used.
Forget that -- I found it. Who came up with the idea of switching on the 9th character of the strings? That confuses Eclipse and me :-( And I find the idea of relying on string features a bit weird if one can have a typesafe enum instead. And switch statements don't add much to Java code until they finally get proper enums. The slightly more consise code doesn't balance the lack of type information -- which helps not only code stability but also people using funny tools to get through the code :-) Looking up usages of constants just won't work if they are not used. Just my 2c, of course.
This is all about speed - one switch statement vs 3-4 string compairs
is at least an order of magnatude faster. Haven't you ever heard of
perfect hashes - that is all this is. A Typesafe enum can't really work
here since you would need to hash or something to find the enum entry
at that requires generating the hash and doing a string compare. This
code is much faster than any other approach really. In a parser it is
all about speed!
Admittably I always forget about the performance bits until later. The confusing bit for me was that there are two sets of constants from CSSConstants and SVGValueConstants which don't seem to do anything at all. I wasn't really aware that I was in parser code and frankly: I didn't know that trick, although it seems obvious now. I'll happily add that to my repertoire.
Another guess at a little code problem: there is this bit of code in org.apache.batik.gvt.renderer.StrokingTextRenderer, line 689ff:
FontRenderContext frc = fontRenderContext; RenderingHints rh = node.getRenderingHints(); // Check for optimizeSpeed, optimizeLegibility // in these cases setup hintedFRC if ((rh != null) && (rh.get(RenderingHints.KEY_TEXT_ANTIALIASING) == RenderingHints.VALUE_TEXT_ANTIALIAS_OFF)) { // In both these cases we want the non-antialiased // font render context. frc = aaOffFontRenderContext; }
which uses one of two predefined FRCs, both using fractional metrics. In CSSUtilities.convertTextRendering(...) (l. 413ff) more options are set, including the fractional metrics. Since the code doesn't seem to be shared too much I suspect there is some inconsistency here. Although the fractional metrics turned off option is already in comments, so it probably does behave as expected as long as noone removes the little slashes. ;-)
But that doesn't explain why the rendering doesn't work as I want it. The code in convertTextRendering gets called and the correct switch branch gets executed. I seem to be looking in the right class, too. But it seems to be too late for me to get through that code and how it makes the difference :-( Maybe tomorrow, all hints are welcome.
The code of interest is in gvt.font.AWTGVTGlyphVector I have put in
print statements and the code is using the 'fill' branch instead of
the drawGlyphVector branch.
That wasn't exactly what I was looking for -- I was trying to work out where the rendering hints are set and where the defaults come from. Is it right that (hints == null) means "use defaults"? In that case I am still a bit suspicious about line 177ff of SVGTextElementBridge:
RenderingHints hints = CSSUtilities.convertTextRendering(e, null);
hints = CSSUtilities.convertColorRendering(e, hints);
if (hints != null) {
node.setRenderingHints(hints);
}Shouldn't the two sets of rendering hints be independent? If either of them is set, hints won't be null, thus neither default will be used. Or did I get it all wrong?
Peter
[...]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
