This was a FOP message, but you're the DOM experts, so I'd like to get your input. ---- The end result we want is that Scalable Vector Graphics (SVG) be translated to PDF. Kieron's been treating SVG sort of as a special case of XSL:FO, which is why it's been [uncommitted, but still] in FOP.
If SVG is going to be DOM based, rather than treated as a special case form of XSL:FO, then that immediately says, "Xerces" to me. Should an implementation of the W3C's SVG DOM be part of Xerces? Does that allow us to do anything cool? Should it continue to be part of FOP? If so, how can we be consistant with the Xerces stuff? -Steve -----Original Message----- From: Keiron Liddle [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2000 7:08 AM To: fop-dev@xml.apache.org Subject: SVG I've had a look at the SVG dom classes. I will be moving all the svg code into this model once I figure out a few things. This means some major restructuring. This raises some questions. should the implementation be placed in org.apache.svg.dom.* should all implementation classes be called <interface name>Impl.java Is it possible to have property makers (ie. "propertyTable.put("width",SVGLengthProperty.maker())") that applies only to a particular xml element or maybe xml namespace. If not then there will be some problems with properties in svg and fop that have the same name but need to return different objects (without making Property bloated). Also in svg the text element can have a list of x values that should parse the property into a list, other x values should only be a single number. COFFMAN Steven wrote: > In PDF, SVG, XSL, etc. we're flinging RGB floating point color components > around. I'd like to fling a color object around instead. The SVG color object will be the implementation of the org.w3c.dom.svg.SVGColor which holds an RGBColor
