Hi, it was rumored this week that there is a SVG import filter for OOdraw 2.0 beta out there. This is partially true.
Invited by Stefan and Kai, I'd like to shortly introduce myself and my SVG import project to start a discussion about further steps. I'm very interested in transformation systems and XML technology. Long time ago, I stumbled across a SVG that I liked to further edit in OOdraw, but that persistently resisted against being imported. I don't want to bother you with details about how I came to writing this transformation, but I want to mention that the publication of the Oasis OpenDocument 1.0 format was one motivation. I'm just enthusiastic about now having full control over my own documents. Thanks! As already expressed in posts to Issue 2497, I'm convinced that transformation from SVG to OpenDocument is not possible in a sense that the resulting image is indistinguishable from the rendered SVG version *and* that the result is still editable in a reasonable way. The existing filter tries to perform an approximation that is a compromise between accuracy and structure preservation. The svg-import project currently consists of four "sub-projects": 1. The OpenOffice integration component, which provides an XImportFilter. This filter builds an annotated SVG DOM tree using batik, transforms it into an OpenDocument DOM tree using svg2office and finally translates this OpenDocument DOM into SAX events, which are feed into the OpenOffice-provided XDocumentHandler. 2. The svg2office transformation is structured as visitor of a SVG DOM tree, which is provided by batik. During its visit, the transformation builds OpenDocument DOM nodes. For the OpenDocument DOM, currently, a generic DOM implementation is used (provided by javax.xml). To avoid writing string constants and to have at least some sort of type checking and IDE support, facade classes are generated directly from the RelaxNG schema of OpenDocument. This is accomplished by rng2dom. The transformation itself mainly relies on the information provided by the SVG DOM API as specified by w3.org. Only where this is not sufficient, implementation details from the Apache batik SVG engine are used. This means, that the transformation is not built as batik backend (a transcoder that acts on behalf of the batik-internal GVT rendering tree). The batik-internal GVT rendering tree is therefore only consulted, where context information is required, which is not offered by the SVG DOM. 3. rng2dom is a set of transformations that prepare a RelaxNG schema for data-binding. The transformations that are implemented are relatively advanced, but the generated facade classes do not make much use of theses features yet. The OpenDocument DOM facade simply provides a bunch of methods to create elements from the different OpenDocument namespaces and to get and set attributes for these elements in a more or less generic fashion. This sub-project is no integral part of svg-import, since the only dependency is the generated access code for the OpenDocument DOM. 4. A (minimally) hacked version of batik. That's a pity, but batik was not primarily designed to offer it's SVG DOM to third parties. All transcoders in batik rely on the internal GVT tree for rendering, not for transformation. Therefore, the implementation of "advanced" features of the SVG DOM (like non-exposed subtrees for certain elements) are not yet implemented. To make svg-import more complete, some more effort is necessary to evolve missing features in batik. Ah, before I forget, the filter is implemented in Java 5.0. People already complained about that. But, this filter is a fun project of mine and writing type casts is not fun. I'm not responsible for "them" not having made the future save for the past as originally proposed. :-) But since this SVG thing is not a core component of OpenOffice,... Apart from missing services in third- and second-party components, there are also deficiencies in the OpenOffice implementation of OpenDocument and in OpenDocument itself. Keywords are: - elliptic arcs - gradients - group opacity - markers - clipping But I think, this discussion should be done in a separate thread or on a wiki page. Stefan suggested wiki.services.openoffice.org? Best regards and curious to hear your comments Bernhard --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
