On 4/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi Seth, > > "Seth Tager" <[EMAIL PROTECTED]> wrote on 04/06/2006 06:13:13 PM: > > > ...I'm not sure I understand your > > statement about 'creating classes to hold the data between DOM and > > GVT'. I think you're suggesting that one way to decouple them would be > > to create an intermediate set of classes to hold the data and then > > pass the data objects off to some object in gvt that would build the > > tree. Another way would be to require bridge clients (like gvt) to > > implement an interface, and then have the clients build the tree > > themselves as the document is parsed. > > In the end I don't think there is a large difference between the > two. Perhaps you save some intermediate memory but if I give you > an java.awt.Path with the data what is the difference from calling > 20 different methods (like PathParser does)? You can pull the data > out of the path object at least as easily as implement the PathHandler > interface...
I think you lose the potential to handle dynamic content. I'm not concerned about dynamic content at the moment, but if I'm thinking about a general solution I figure I should work toward one that would support it in theory. > > Here's what I've done so far and where I'm headed. Since I have > > limited batik experience, please let me know if you think I'm > > looking for trouble. > > Well, I'm not sure what you code looks like so it's a little hard > to say. I'll say that in general the most challenging parts of batik > are the 'use' element, and 'text' (text is _really_ hard). Also of > course efficient dynamic updates are tricky (dependency tracking). I did notice a lot of code related to dynamic updates, and I see a lot of classes and complexity around text, but I appreciate the confirmation of where the rough spots might be. I didn't notice anything related to the 'use' element, so I'll look for that. > > ... It seems to me that a framework > > for building arbitrary class trees from svg would do much to promote > > svg as it would lower the barrier to entry for 3rd party projects that > > wanted to read svg and transform it to their internal data format. > > I don't know for certain but it seems to me that this interface would > be huge (filters, clips, patterns, gradients, fill, stroke, use) I > would expect that many people would prefer to implement the Graphics2D > interface to import SVG data - it may be useful for importing other data > as well. However it can be a bit lossy. I hadn't thought of that, and it sounds like the easier way to go for some situations, but the lossy aspect is important. I assume things like filters get transformed into drawImage calls, which is what you mean by lossy, no? > I really don't think I follow you here. Do you care to share your > work so far? I'd be happy to send it to you. I tried posting it to the list about a week ago but it was rejected as being too large (300k). I cc'd you directly, but I didn't get a reply so I'm not sure if you got it. Can I send you a copy offline? Seth --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
