xmlgraphics-batik-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Haneman <Bill.Hane...@ireland.sun.com>
Subject Re: [bugs] Filter bounds vs. getPrimitiveBounds
Date Tue, 12 Dec 2000 18:07:37 GMT
I said:

>> Primitive bounds are what are
>> needed for filters.  The question is how we implement
>> this change.  But without it filters will not work
>> as one wishes.


>Yes it is. See SVG spec : 7.11 Object bounding box units 
>"The bounding box is the tightest fitting rectangle ...

I didn't doubt that geometryBounds were right for the bounding
box.  The issue I had in mind was with the "correct" behavior
of filters.  I was not sure that filters were supposed to use
this bounding box for default sizing.

You may recall that the last time I had text elements report 
their geometric bounding box I was blamed for a regression ;-)
(text underlining in index2.svg failed to make it through
the blur filter).

But on reflection you are right, that was really a pre-existing 
bug in the SVG file and not really a regression. I was basing my 
(mis-)understanding on this previous issue.

>Notice that you have the x, y, width and height attributes that let 
users grow 
>the filter region if needed (taking into account the stroke...).

I agree, if it's true that filters are supposed to use the
object bounding box then this seems like the right way to
get filters to "do as one wishes".

Are we agreed that this is the right interpretation of
the spec?


>Thierry Kormann
>email: Thierry.Kormann@sophia.inria.fr  
>Koala/Dyade/Bull @ INRIA - Sophia Antipolis
>To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
>For additional commands, e-mail: batik-dev-help@xml.apache.org

Bill Haneman +353 1 8199279
Ireland Desktop Engineering
Sun Microsystems Ireland Ltd.

View raw message