> > >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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
