Extending batik: simplest "transparent" element

[Antonio Fiol Bonnín <fi...@terra.es>]

Hello,

I have started to implement what I posted on my previous e-mail, and my 
first try has been a simple transparent wrapper element.

The idea:

<svg:svg>
<ext:wrapper>
<svg:circle />
</ext:wrapper>
</svg:svg>

should be rendered exactly as if it was:

<svg:svg>
<svg:circle />
</svg:svg>

Or more precisely, as:

<svg:svg>
<svg:g>
<svg:circle />
</svg:g>
</svg:svg>


What I did:

Created a DOM extension.
Created a bridge extension.
Created an element.
Created a bridge.

If I launch the browser loading a file which contains the <ext:wrapper> 
thing, I see the constructors being called, for the bridge, and for the 
element.

However, the bridge method for generating a GVT node are NEVER called.

Why is that?

Am I doing something wrong?


Thank you very much.


Antonio Fiol


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

Re: Extending batik: simplest "transparent" element

[Antonio Fiol Bonnín <fi...@terra.es>]

>
>
>AFB> I need no Java2D at all. But I need to make things
>AFB> appear/disappear/change depending on (a set of) Java variables
>AFB> which represent the state of an automation system.
>
>     Once again I don't know the details but this might be easily
>accomplished by manipulating the SVG DOM directly from Java.  For
>simple things (like making things visible/hidden) this can be easy,
>however if you have more complex changes (like updating the 'angle' of
>a line based on a reading) you may end up 'replicating' this logic in
>the XSLT and the Java code.
>
>AFB> So, to use XSLT I would have to generate some dynamic XML which
>AFB> would change only a little bit, every time a variable
>AFB> changes. Then I would have to do an entire transform, and an
>AFB> entire render.
>
>     This is an option, the other is to manipulate the SVG DOM instead
>of the 'high level' DOM.  I realise that this might not be 'good' in
>your case.
>
>AFB> If I use custom "g" components that make their content be
>AFB> rendered/not rendered, I only would need to do the entire render,
>AFB> thus being much more efficient.
>
>     Essentially the same logic to map changes in the custom element
>to changes in the SVG DOM would need to be implemented here.  Although
>it would be easier to avoid the temptation to break encapsulation this
>way.
>
>     My concern here is that this approach 100% binds you to a
>specific SVG renderer (Batik).  If you can limit your code to
>manipulating the SVG-DOM you may be able to work with other SVG
>renderers 'down the road'.  If you are already 100% bound then this
>isn't really and issue.
>


I understood your concern perfectly, and that is essentially why I said 
that I would use some "brain cycles" to study that.

I have done that.

So... what I really need is:

To extend SVG and write a "proprietary format" --> "extended SVG" 
conversion program.

Proprietary format includes simple shapes and a finite number of 
different behaviours, such as:
- appear/disappear depending on variable value (equality or range) for 
any graphical form
- show a variable value (number value), or choose a text from a list 
depending on numerical/boolean variable value for text elements
- chronogram-like animations showing the history of a variable's values 
(I'll see those later)

So, you see, transforms are really simple, but the SVG DOM is not known 
"a priori". It needs to be created from the (loaded) extended SVG, plus 
the variable values.

So I cannot (or do not know how) to modify the pure SVG DOM. That is why 
I thought of extending.

I see your point on portability, and I think I'll give XSLT a try. 
Because otherwise I will be facing the fact that batik is ignoring 
unknown elements, even if they contain valuable SVG inside them.

The only drawback apart from performance is that I will have to do the 
following:

Load extended SVG.

Transform it using a XSL to make a --generated-- XSL which transforms...

...a dynamically created DOM containing the variables information, with 
no graphics information...

into SVG.

I would also need a second static XSL that transforms the loaded SVG 
into an empty DOM containing the variables information. This is the DOM 
I could update.

What do you think about this approach?


Antonio Fiol


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

Re: Extending batik: simplest "transparent" element

[Thomas E Deweese <th...@kodak.com>]

>>>>> "AFB" == Antonio Fiol Bonnín <fi...@terra.es> writes:

>> 
>> 
>> I must say that I have a few reservations about the general
>> technique of adding new elements to SVG.  I don't really know what
>> your constraints are but you might consider using a transformation
>> language like XSLT to map your custom grammer into standard SVG.
>> 

AFB> I will use some brain cycles to process that idea. I had not
AFB> previoulsy thought of that.

>> However if you really need to be able to use Java2D to do rendering
>> of the element this approach is probably the only feasable one.
>> 

AFB> I need no Java2D at all. But I need to make things
AFB> appear/disappear/change depending on (a set of) Java variables
AFB> which represent the state of an automation system.

     Once again I don't know the details but this might be easily
accomplished by manipulating the SVG DOM directly from Java.  For
simple things (like making things visible/hidden) this can be easy,
however if you have more complex changes (like updating the 'angle' of
a line based on a reading) you may end up 'replicating' this logic in
the XSLT and the Java code.

AFB> So, to use XSLT I would have to generate some dynamic XML which
AFB> would change only a little bit, every time a variable
AFB> changes. Then I would have to do an entire transform, and an
AFB> entire render.

     This is an option, the other is to manipulate the SVG DOM instead
of the 'high level' DOM.  I realise that this might not be 'good' in
your case.

AFB> If I use custom "g" components that make their content be
AFB> rendered/not rendered, I only would need to do the entire render,
AFB> thus being much more efficient.

     Essentially the same logic to map changes in the custom element
to changes in the SVG DOM would need to be implemented here.  Although
it would be easier to avoid the temptation to break encapsulation this
way.

     My concern here is that this approach 100% binds you to a
specific SVG renderer (Batik).  If you can limit your code to
manipulating the SVG-DOM you may be able to work with other SVG
renderers 'down the road'.  If you are already 100% bound then this
isn't really and issue.

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

Re: Extending batik: simplest "transparent" element

[Antonio Fiol Bonnín <fi...@terra.es>]

>
>
>     I must say that I have a few reservations about the general
>technique of adding new elements to SVG.  I don't really know what
>your constraints are but you might consider using a transformation
>language like XSLT to map your custom grammer into standard SVG.
>

I will use some brain cycles to process that idea. I had not previoulsy 
thought of that.

>     However if you really need to be able to use Java2D to do
>rendering of the element this approach is probably the only feasable
>one.
>

I need no Java2D at all. But I need to make things 
appear/disappear/change depending on (a set of) Java variables which 
represent the state of an automation system.

So, to use XSLT I would have to generate some dynamic XML which would 
change only a little bit, every time a variable changes. Then I would 
have to do an entire transform, and an entire render.

If I use custom "g" components that make their content be rendered/not 
rendered, I only would need to do the entire render, thus being much 
more efficient.


>AFB> What I did:
>
>AFB> Created a DOM extension.  Created a bridge extension.  Created an
>AFB> element.  Created a bridge.
>
>AFB> If I launch the browser loading a file which contains the
>AFB> <ext:wrapper> thing, I see the constructors being called, for the
>AFB> bridge, and for the element.
>
>AFB> However, the bridge method for generating a GVT node are NEVER
>AFB> called.
>
>AFB> Why is that?
>
>     I suspect that you are not registering them with the DOM
>implementation or the BridgeContext.  If not you probably want to look
>at batik.extensions.svg.BatikDomExtension, and
>batik.extensions.svg.BatikBridgeExtension.  Note that on top of
>writing these classes you need to create a 'services' file, take a
>look at the contents of 'xml-batik/resources/META-INF/services/', and
>'http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Service Provider'.
>

I did look at those files, and used the registering methods at them 
(copy+paste+modify to suit my names).

I created the services file and...

the constructors of my custom element _and_ bridge *are* both called.

But then, once constructed, the bridge is *not* used at all.

The constructor is probably called at the registering stage.

May I send you the sources I have for you to look at? I am relly stuck 
on this.

Thank you very much for all your attention.



Antonio Fiol



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

RE: Extending batik: simplest "transparent" element

[Thomas E Deweese <th...@kodak.com>]

>>>>> "AFB" == Antonio Fiol Bonnín <fi...@terra.es> writes:

AFB> I have started to implement what I posted on my previous e-mail,
AFB> and my first try has been a simple transparent wrapper element.

     I must say that I have a few reservations about the general
technique of adding new elements to SVG.  I don't really know what
your constraints are but you might consider using a transformation
language like XSLT to map your custom grammer into standard SVG.

     However if you really need to be able to use Java2D to do
rendering of the element this approach is probably the only feasable
one.

AFB> The idea:

AFB> <svg:svg> <ext:wrapper> <svg:circle /> </ext:wrapper> </svg:svg>

AFB> Or more precisely, as:

AFB> <svg:svg> <svg:g> <svg:circle /> </svg:g> </svg:svg>


AFB> What I did:

AFB> Created a DOM extension.  Created a bridge extension.  Created an
AFB> element.  Created a bridge.

AFB> If I launch the browser loading a file which contains the
AFB> <ext:wrapper> thing, I see the constructors being called, for the
AFB> bridge, and for the element.

AFB> However, the bridge method for generating a GVT node are NEVER
AFB> called.

AFB> Why is that?

     I suspect that you are not registering them with the DOM
implementation or the BridgeContext.  If not you probably want to look
at batik.extensions.svg.BatikDomExtension, and
batik.extensions.svg.BatikBridgeExtension.  Note that on top of
writing these classes you need to create a 'services' file, take a
look at the contents of 'xml-batik/resources/META-INF/services/', and
'http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Service Provider'.


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