Mailing-List: contact batik-users-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Batik Users" <batik-users@xml.apache.org>
Message-ID: <3F66E545.5010608@dstc.edu.au>
Date: Tue, 16 Sep 2003 20:26:13 +1000
From: Peter Becker <pbecker@dstc.edu.au>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: Batik Users <batik-users@xml.apache.org>
Subject: Re: Text rendering changes after upgrade to 1.5
References: <3F5EB9BC.4070208@dstc.edu.au> <3F5EF0A0.5080308@Kodak.com>
 <3F5FCB7B.7090102@dstc.edu.au> <3F60435C.6020200@Kodak.com>
 <3F61C582.3010904@dstc.edu.au> <3F645C3E.9000908@Kodak.com>
In-Reply-To: <3F645C3E.9000908@Kodak.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Thomas,

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?

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.

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.


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.

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.

  Peter


PS: please don't misread my aggressive approach to code reviews as 
ungratefulness or arrogance ;-) My code is not better -- the only code 
you really like is your code from today. And Batik definitely has great 
support :-)


Thomas DeWeese wrote:

[...]

>>> 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). 
>>
>>
>>
>> Hi Thomas,
>>
>> that doesn't seem to work. If I use this:
>>
>>                  <text x="8" y="16" 
>> style="filter:url(#Shadow);font-family:Arial;font-size:14;stroke-width:0;stroke-opacity:1;stroke:rgb(220,220,255);fill-opacity:1;fill:rgb(220,220,255);opacity:1;text-rendering:geometricPrecision" 
>> id="xweb">oops</text>
>
>
>    Ooops is right.  It didn't properly pick up on the hint in JDK 
> 1.4.1 (it
> worked in 1.3.1).
>
>> I get the same look as without the rendering hint. If I use 
>> optimizeLegibility instead I do get a slight change, so the hint 
>> seems to work, it is just that geometricPrecision doesn't give the 
>> same result as the old version (while being the default).
>
>
>   This will be fixed in CVS today.
>
>> Is there any reference rendering how text should look like? The old 
>> version was pretty much in agreement with Adobe's viewer so I was 
>> happy. Now the difference is rather significant. :-( I haven't tried 
>> other tools, though.
>>
>> Is there any way to get the old behavioiur back? I'm happy to hack 
>> some more code if I get the right hints ;-)
>
>
>   With the hint behaviour fixed you should get exactly the same rendering
> as before.  Also thinking about this, the simplest way to turn this on
> is to use a CSS user style sheet. This is already available on the 
> command
> line of the rasterizer.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-users-help@xml.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org