>>>>> "TK" == Thierry Kormann <[EMAIL PROTECTED]> writes:
TK> On Tuesday 10 July 2001 19:38, Thomas E Deweese wrote: Hi,
>> Since this is your 100% typical speed vs. quality tradeoff it seems
>> pretty clear that for color-rendering (perhaps shape rendering?)
>> set to optimizeSpeed gradient anti-aliasing should be off for
>> optimizeQuality it should be on. This of course leaves the
>> question of what to do in the default case.
TK> That makes sence.
TK> I agree that the default should by antialisingOff.
Well, actually I wasn't proposing that :)
Please take a look at samples/tests/radialGradient2.svg with and
without the anti-aliasing code before deciding anti-aliasing should be
off (you need to play with the USE_ANTI_ALIAS static in
RadialGradientPaintContext).
>> My question is for Thierry or Vincent. Is the optmizeXXX stuff
>> working yet? If so how are the hints mapped?
TK> Yes. shape-rendering, text-rendering and image-rendering
TK> properties are working. You have some examples that illustrate the
TK> mapping between J2D rendering hints and SVG rendering hints in the
TK> sample/tests directory.
Good!
Should I key off shape-rendering or color-rendering? Neither is a
great fit but I think of shape-rendering as just the edges of
filled/stroked objects, color-rendering starts getting to how precise
the rendering engine should be about color handling. I guess for now
I'll key off shape-rendering since that is implemented.
>> Finally, Thierry, as I recall there was some debate over how
>> gradients that use the same stop value twice should be handled,
>> what is implemented in Batik doesn't match my recollection of the
>> discussion. Right now Batik deletes the first stop at the value, I
>> think it should keep it and have the gradient have a discontinuity:
TK> [...] So I already do lots of things in the gradient bridges. I
TK> could do that one if you think it's my job (I think it
TK> is). Anyway, the previous implementation of the gradients handles
TK> the case of 2 offsets with the same value and do what the spec
TK> says, so I just ignore this one in the bridge.
Just an FYI, the bridge was killing the previous stop, so it never
made it to the gradient code (which does properly handle the case).
My small fix in the abstract gradient bridge class fixed this. My new
test tests this case as well.
>> If you agree with my thinking then I will check in an updated
>> version of the gradient bridge that does this.
TK> I do (a bit late :)
Sorry, didn't mean to jump the gun on the commit, I assumed
Christophe had talked with you. :)
Thanks!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
