You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by George Armhold <ar...@cs.rutgers.edu> on 2003/12/09 09:52:36 UTC
setAttribute vs setAttributeNS
Can someone please explain the difference between Element.setAttribute
and Element.setAttributeNS(), as it affects Batik? My code loads a
document into the canvas and performs various modifications to the DOM,
adding various <g>, <rect> and <line> Elements. I notice that through
accretion, my code is using all of the following in various places:
e.setAttribute(attribName, attribValue);
e.setAttributeNS(svgNS, attribName, attribValue);
e.setAttributeNS(null, attribName, attribValue);
It seems that some attribs need the SVG namespace (e.g. the xml "id"
attrib.) Others are happy with no namespace (<line> x/y coords.) Yet
others seem to need the null namespace (the width/height of the <svg>
element.) Are there some general rules about when & how to supply a
namespace for attributes?
Thanks
--
George Armhold
Rutgers University
eLearning Grant, DCIS
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: setAttribute vs setAttributeNS
Posted by Thomas DeWeese <Th...@Kodak.com>.
George Armhold wrote:
> Thomas DeWeese wrote:
>
>> Fortunately this example can be done about as simply by
>> defining a pattern that uses the background content and setting
>> the pattern as the fill for the lines. You need to setup the
>> patternUnits and patternContent units properly but this should
>> not be significantly more difficult than setting up feImage
>> and the filter properly.
>
>
> Your suggestion of using a pattern turned out to actually be easier to
> implement than the equivalent code using a filter. However I very
> quickly run out of memory (even on simple docs) using this technique. I
> now have a document that looks like this:
Ahh, yah, for complex SVG it will copy the SVG content for each
instance of the pattern (i.e. each line). Ideally it would detect
when the pattern instances match and reuse the graphics tree (in
thinking about this I think the pattern's associated graphics tree can
always be reused across uses each may have a different associated
pattern transform).
one other approach would be clip, but this will be problematic
as clip doesn't apply stroke. so you would have to 'draw' the
wide lines yourself (although for single lines it's pretty easy
- circle/elliptical arc, rect/line to, circle/elliptical arc).
> <svg>
> <defs>
> <pattern id="bgPattern"
> patternUnits="userSpaceOnUse"
> width="100%" height="100%">
>
> <g>
> <!-- insert background image code here -->
> </g>
>
> </pattern>
> </defs>
>
> </svg>
>
> Now whenever the user draws with the mouse I add <line> elements that
> specify bgPattern as the stroke pattern. This works, but extremely
> slowly. It also very quickly uses up about 280MB of RAM before
> getting an OutOfMemoryErrorException.
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: setAttribute vs setAttributeNS
Posted by George Armhold <ar...@cs.rutgers.edu>.
Thomas DeWeese wrote:
> Fortunately this example can be done about as simply by
> defining a pattern that uses the background content and setting
> the pattern as the fill for the lines. You need to setup the
> patternUnits and patternContent units properly but this should
> not be significantly more difficult than setting up feImage
> and the filter properly.
Your suggestion of using a pattern turned out to actually be easier to
implement than the equivalent code using a filter. However I very
quickly run out of memory (even on simple docs) using this technique. I
now have a document that looks like this:
<svg>
<defs>
<pattern id="bgPattern"
patternUnits="userSpaceOnUse"
width="100%" height="100%">
<g>
<!-- insert background image code here -->
</g>
</pattern>
</defs>
</svg>
Now whenever the user draws with the mouse I add <line> elements that
specify bgPattern as the stroke pattern. This works, but extremely
slowly. It also very quickly uses up about 280MB of RAM before
getting an OutOfMemoryErrorException.
--
George Armhold
Rutgers University
eLearning Grant, DCIS
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: setAttribute vs setAttributeNS
Posted by George Armhold <ar...@cs.rutgers.edu>.
Thomas DeWeese wrote:
> This won't work in Batik currently. When the size of the 'g' with
> the filter changes (because children are added) we don't currently
> rebuild the filter so it keeps it's old bounds.
OK, too bad. I can see how it's a complicated situation though, so I
understand.
> Fortunately this example can be done about as simply by defining a
> pattern that uses the background content and setting the pattern as
> the fill for the lines. You need to setup the patternUnits and
> patternContent units properly but this should not be significantly
> more difficult than setting up feImage and the filter properly.
The example I gave was a somewhat simplified one. Normally we are
using a filter on a much more complicated <g>, not just a simple
image. We're taking an existing SVG doc, stuffing it into a new <g>
tag which becomes the "background" image used by the filter. Then we
draw on top of this. Then the user can selectively erase parts of his
drawing, revealing the underlying background <g>. Will the pattern
strategy you outline above work for this situation in Batik? I need
to do some more reading before I can entirely understand your answer
(patternUnits, patternContent, etc,)
> This is a general problem in Batik that 'indirect' references like
> this are generally not tracked dynamically. We did do some of this
> early on but discovered that it introduced huge memory leaks and
> backed it out.
I did notice that my machine sometimes comes to a grinding halt due to
swapping when I attempt this sort of thing in batik.
Thanks again for your help.
--
George Armhold
Rutgers University
eLearning Grant, DCIS
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: setAttribute vs setAttributeNS
Posted by Thomas DeWeese <Th...@Kodak.com>.
George Armhold wrote:
> Thomas DeWeese wrote:
>
>> It is possible that we do not calculate the effected bounds of
>> the change to the document when the filter effect is added (although
>> in my testing this has worked). I'll try and take a look.
>
>
> Well I hacked it down, and now my "short" example program is over 200
> lines. I hope this won't be too painful for you. The program
> dynamically creates a document that looks like the following:
[...]
> First, it displays an image from a .jpg file. Then it draws a white
> rectangle which partially obscures the image. Then the user can
> "erase" parts of this rectangle by drawing with the left mouse button,
> to reveal the image again. You'll see that the drawing doesn't seem
> to update properly. If you then click the right mouse button, the doc
> will get re-loaded, and the drawing thus becomes visible.
This won't work in Batik currently. When the size of the 'g'
with the filter changes (because children are added) we don't
currently rebuild the filter so it keeps it's old bounds.
Fortunately this example can be done about as simply by
defining a pattern that uses the background content and setting
the pattern as the fill for the lines. You need to setup the
patternUnits and patternContent units properly but this should
not be significantly more difficult than setting up feImage
and the filter properly.
This is a general problem in Batik that 'indirect' references
like this are generally not tracked dynamically. We did do some
of this early on but discovered that it introduced huge memory
leaks and backed it out. I think our infrastructure for tracking
these sorts of things has improved to a point where we might be
able to add it back but not before the 1.5.1 release (there are
one or two remaining issues I want to try and fix before that
release).
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: setAttribute vs setAttributeNS
Posted by George Armhold <ar...@cs.rutgers.edu>.
Thomas DeWeese wrote:
> It is possible that we do not calculate the effected bounds of
> the change to the document when the filter effect is added (although
> in my testing this has worked). I'll try and take a look.
Well I hacked it down, and now my "short" example program is over 200
lines. I hope this won't be too painful for you. The program
dynamically creates a document that looks like the following:
<svg>
<defs>
<filter xmlns:xlink="http://www.w3.org/1999/xlink"
filterUnits="objectBoundingBox"
xlink:type="simple"
xlink:actuate="onRequest"
id="filter-bgGroup"
xlink:show="replace">
<feImage result="background"
xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="#bgGroup"
xlink:type="simple"
xlink:actuate="onRequest"
xlink:show="replace"/>
<feComposite operator="in" in2="SourceGraphic" in="background"/>
</filter>
</defs>
<g style="stroke:black; stroke-opacity:1; stroke-linejoin:round;
stroke-linecap:round; fill:black; stroke-width: 20px; " id="bgGroup">
<image x="0" y="0"
width="100%" height="100%"
xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://erudycja.rutgers.edu/~armhold/svg/eiffel.jpg"
xlink:type="simple"
xlink:actuate="onRequest"
preserveAspectRatio="xMidYMid meet"
xlink:show="replace"/>
</g>
<rect x="10%" y="20%"
width="80%" height="60%"
fill="white"/>
<g style="stroke:black; stroke-opacity:1; stroke-linejoin:round;
stroke-linecap:round; fill:black; stroke-width: 20px; filter:
url(#filter-bgGroup);" id="drawing_group">
</g>
</svg>
First, it displays an image from a .jpg file. Then it draws a white
rectangle which partially obscures the image. Then the user can
"erase" parts of this rectangle by drawing with the left mouse button,
to reveal the image again. You'll see that the drawing doesn't seem
to update properly. If you then click the right mouse button, the doc
will get re-loaded, and the drawing thus becomes visible.
I hope this will be useful. Thanks as always for looking into this.
--
George Armhold
Rutgers University
eLearning Grant, DCIS
Re: setAttribute vs setAttributeNS
Posted by Thomas DeWeese <Th...@Kodak.com>.
George Armhold wrote:
> Thomas DeWeese wrote:
> I'm creating a new filter each time. Unfortunately the code is rather
> complex. I'm trying to boil it down to something digestible.
>
> In brief, here's what I'm doing.
>
> 1. Dynamically create simple SVGDocument (runs in the Swing thread.)
> 2. Add filter to SVGDocument.
> 3. setSVGDocument(theDoc);
> 4. In UpdateManager thread, add <line> segments that use the new
> filter.
> 5. Expect to see filter effects, but get nothing, or garbled graphics.
It is possible that we do not calculate the effected bounds of
the change to the document when the filter effect is added (although
in my testing this has worked). I'll try and take a look.
> If I then do a setSVGDocument(getSVGDocument()) the canvas updates as
> expected, and I see the filter effects correctly.
Hmmm....
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: setAttribute vs setAttributeNS
Posted by George Armhold <ar...@cs.rutgers.edu>.
Thomas DeWeese wrote:
> Dynamic modifications to an existing filter are not currently
> tracked. If you create a new filter and set the filter property on
> an element it should update.
> If the above does not sound like your problem I'll take a look
> at your example.
I'm creating a new filter each time. Unfortunately the code is rather
complex. I'm trying to boil it down to something digestible.
In brief, here's what I'm doing.
1. Dynamically create simple SVGDocument (runs in the Swing thread.)
2. Add filter to SVGDocument.
3. setSVGDocument(theDoc);
4. In UpdateManager thread, add <line> segments that use the new
filter.
5. Expect to see filter effects, but get nothing, or garbled graphics.
If I then do a setSVGDocument(getSVGDocument()) the canvas updates as
expected, and I see the filter effects correctly.
--
George Armhold
Rutgers University
eLearning Grant, DCIS
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: setAttribute vs setAttributeNS
Posted by Thomas DeWeese <Th...@Kodak.com>.
George Armhold wrote:
> Thomas DeWeese wrote:
>
> > Well it is always required for createElementNS. Perhaps you
> > switched all of your createElement/setAttribute calls to
> > createlementNS(svgns,...)/setAttributeNS(svgns,...) And since
> > something suddenly started appearing you lumped the two together?
>
> This sounds pretty likely.
>
> >> I'll go normalize all my code. If something breaks, I'll report
> >> back.
>
> I normalized everything to:
>
> setAttributeNS(null, attribName, attribValue),
>
> and there's no apparent breakage. Thanks again for that. So now that
> I know my attributes are set correctly, I'll have to look elsewhere
> for the solution to my problem (filters not working correctly.)
> Does Batik support adding filters to the <defs> section dynamically?
Dynamic modifications to an existing filter are not currently
tracked. If you create a new filter and set the filter property on
an element it should update.
If the above does not sound like your problem I'll take a look
at your example.
> I'm trying to draw using a background image (see
> http://elearning.rutgers.edu/~armhold/svg/erase). The filters don't
> seem to have any effect in the current canvas. When the doc is
> written out to disk and then re-loaded, it works fine. PS: although
> the example on that page uses SMIL animation, my code is not using
> that; I know it's not supported in Batik.
>
> Thanks!
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: setAttribute vs setAttributeNS
Posted by George Armhold <ar...@cs.rutgers.edu>.
Thomas DeWeese wrote:
> Well it is always required for createElementNS. Perhaps you
> switched all of your createElement/setAttribute calls to
> createlementNS(svgns,...)/setAttributeNS(svgns,...) And since
> something suddenly started appearing you lumped the two together?
This sounds pretty likely.
>> I'll go normalize all my code. If something breaks, I'll report
>> back.
I normalized everything to:
setAttributeNS(null, attribName, attribValue),
and there's no apparent breakage. Thanks again for that. So now that
I know my attributes are set correctly, I'll have to look elsewhere
for the solution to my problem (filters not working correctly.)
Does Batik support adding filters to the <defs> section dynamically?
I'm trying to draw using a background image (see
http://elearning.rutgers.edu/~armhold/svg/erase). The filters don't
seem to have any effect in the current canvas. When the doc is
written out to disk and then re-loaded, it works fine. PS: although
the example on that page uses SMIL animation, my code is not using
that; I know it's not supported in Batik.
Thanks!
--
George Armhold
Rutgers University
eLearning Grant, DCIS
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: setAttribute vs setAttributeNS
Posted by Thomas DeWeese <Th...@Kodak.com>.
George Armhold wrote:
> Thomas DeWeese wrote:
> At some point in the distant past I came to believe that the svgNS had
> to be specified for certain attribs. Too long ago to remember
> how or why I developed this misconception.
Well it is always required for createElementNS. Perhaps you
switched all of your createElement/setAttribute calls to
createlementNS(svgns,...)/setAttributeNS(svgns,...) And since
something suddenly started appearing you lumped the two together?
Anyway I'm pretty sure I've never used svgns for setAttributeNS.
>> If you can provide a small reproducible example to the contrary I
>> would be very interested in seeing it but I do a fair amount of this
>> stuff and I always just use 'setAttribute' (except of course for
>> 'xlink:href').
>
> I'll go normalize all my code. If something breaks, I'll report
> back.
Please do.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: setAttribute vs setAttributeNS
Posted by George Armhold <ar...@cs.rutgers.edu>.
Thomas DeWeese wrote:
> I think you have fooled your self.
Yeah, well I'm pretty good at that sometimes. :-)
> For all intents and purposes _nothing_ uses e.setAttributeNS(svgNS,
> ...) - I don't know where you got the impression you needed to do
> this for 'id' you do not.
At some point in the distant past I came to believe that the svgNS had
to be specified for certain attribs. Too long ago to remember
how or why I developed this misconception.
> In Batik setAttribute(attribName, attribValue) is exactly the same
> as setAttributeNS(null, attribName, attribValue).
Thanks.
> If you can provide a small reproducible example to the contrary I
> would be very interested in seeing it but I do a fair amount of this
> stuff and I always just use 'setAttribute' (except of course for
> 'xlink:href').
I'll go normalize all my code. If something breaks, I'll report
back. Thanks again!
--
George Armhold
Rutgers University
eLearning Grant, DCIS
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org
Re: setAttribute vs setAttributeNS
Posted by Thomas DeWeese <Th...@Kodak.com>.
Hi George,
George Armhold wrote:
> Can someone please explain the difference between Element.setAttribute
> and Element.setAttributeNS(), as it affects Batik? My code loads a
> document into the canvas and performs various modifications to the DOM,
> adding various <g>, <rect> and <line> Elements. I notice that through
> accretion, my code is using all of the following in various places:
>
> e.setAttribute(attribName, attribValue);
> e.setAttributeNS(svgNS, attribName, attribValue);
> e.setAttributeNS(null, attribName, attribValue);
Wow! :)
> It seems that some attribs need the SVG namespace (e.g. the xml "id"
> attrib.) Others are happy with no namespace (<line> x/y coords.) Yet
> others seem to need the null namespace (the width/height of the <svg>
> element.) Are there some general rules about when & how to supply a
> namespace for attributes?
I think you have fooled your self. For all intents and purposes
_nothing_ uses e.setAttributeNS(svgNS, ...) - I don't know where you
got the impression you needed to do this for 'id' you do not. For
the 'href' attribute (use, image, etc) you must use
setAttributeNS(xlinkNS, "href", ...) - this is closely related to
'id' perhaps this confused you?
In Batik setAttribute(attribName, attribValue) is exactly the
same as setAttributeNS(null, attribName, attribValue).
Vincent tells me that the "correct" one of setAttribute vs
setAttributeNS(null...) is setAttributeNS(null,...) [I am not as
sure since in some bindings there may be no 'null' value for
DOMString - i.e. C++].
If you can provide a small reproducible example to the contrary
I would be very interested in seeing it but I do a fair amount of
this stuff and I always just use 'setAttribute' (except of course
for 'xlink:href').
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-users-help@xml.apache.org