xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas E Deweese <thomas.dewe...@kodak.com>
Subject Re: GVTBuilder error with custom DOMs
Date Thu, 14 Mar 2002 21:24:17 GMT
>>>>> "JC" == Justin Couch <justin@vlc.com.au> writes:

JC> Vincent Hardy wrote:
>> DOM is an *API* that implementations need to expose. There are
>> generic implementations of that API, such as the ones provided by
>> Xerces or Crimson, and they allow generic manipulation of XML
>> content through the DOM API. However, this is limited to generic
>> manipulation and it is not enough for what is required for SVG
>> processing.

JC> All the XML describes is a collection elements. It really doesn't
JC> matter where those elements are, or how they got created. All they
JC> are is just <rect> here, <line> there and a bunch of css
JC> stuff. Admittedly X3D doesn't have CSS, but a CSS document is no
JC> different to an image, video, audio file, or in our case -
JC> external prototype files. What you do with that DOM is how you get
JC> to the next part.

    This shows a serious lack of knowledge of CSS. CSS effects
everything in SVG. Lets take a look a simple piece of CSS SVG:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"

<svg width="450" height="500" viewBox="0 0 450 500" xml:space="preserve"

     <style type="text/css"><![CDATA[ .fud { fill:red; } ]]></style>
     <rect id="rect" class="fud" fill="blue" style="fill:green" 
           x="10" y="10" width="100" height="100" />

    Can you guess what color the rect is in the following example? 
        The answer is 'green', 

    If you remove the style="fill:green" can you guess what color it is?  
        The answer is 'red'.

    Finally if you change the class or remove the style sheet the
object reverts to blue (what the xml attribute told you all along).

    Please note that you need to support all these possible changes in
response to scripting, and don't forget to redo the CSS cascade
afterwords (i.e. propagate the change on fill to children, like from a
'g' element to it's children elements).  So a change in these
attributes on a single node often propagates down it's entire tree of

    So even if we were to say OK let's go ahead write all our property
handling code twice (once for the case where the DOM has CSS support,
so you have usable performance and once for when the DOM does not).
There are other things in SVG which are even worse.  Let's take a look
at the use element:

<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN"

<svg width="450" height="500" viewBox="0 0 450 500" xml:space="preserve"
     <style type="text/css"><![CDATA[ .fud { fill:red; } ]]></style>
     <rect id="rect" x="10" y="10" width="100" height="100" />
     <use x="240" xlink:href="#rect" fill="orange" />
     <use x="120" xlink:href="#rect" style="fill:purple" />
     <use y="120" xlink:href="#rect" class="fud" />

     The original rect inherits it's fill property from the SVG
element. The others inherit the fill property in various ways from the
use that references them.  This get's even more complex when the
referenced element is from another document, because then it must
respond to CSS selectors from it's own document, but inherit CSS
properties from it's referencing use element (not it's parent in the
referenced document).

     The real kicker here is that the referenced elements must appear
as if it were cloned into the host DOM tree (for event propagation
etc) but must remain unseen by normal DOM traversal (getElementById,
checking children of use etc).

     I just don't know how you would build this on top of a standard
DOM implementation.


     FYI, you are dead wrong about Batik assuming you will use a
transcoder or a Swing component or always doing lots of caching and
having tons of threads, but as with the DOM/CSS issue you took a peek
when it wasn't immedately obvious how to do what you wanted you
assumed we were the idiots (couldn't be that the issues are deeper
then YOU would understand in two days poking around could it?).  In
the future you might try asking questions before forming opinions you
might be wrong less often.

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

View raw message