To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=2497
------- Additional comments from [EMAIL PROTECTED] Sat May 28 09:38:25 -0700 2005 ------- I'm working on this (only from time to time - so do not expect miracles). Unfortunately, I think it's not possible to write a clean-room implementation of the svg2oodraw transformation. One reason for this is that the Open Document format is specified with far less rigor than SVG. Is there somebody out there who is willing to discuss issues in the Open Document format that affects the import from SVG? I mean someone, who has either written the spec or at least slept with it under his pillow? (Hoping for excuse from non-matching literally translated German metaphors :-) Because of the complexity of both formats, I also think it's not an option to simply start with an "almost" working but arbitrary complex XSL(T) and keep fixing until people get tired filing bug reports. A far better approach would be to first specify how features of SVG could be expressed (or at least simulated) in Open Document format. To be more concrete, here are some issues with Open Document format. I think these will prevent OpenOffice from ever being a SVG editor, since structural information which was present in SVG is lost during import and cannot be reconstructed upon export. 1) There is no equivalence for svg:symbol/svg:use. (Is this true?) This means that all references to graphical shape definitions must be expanded during import in OOoffice. From an SVG editor's perspective it's like an editor for C programs would first expand all macro definitions. You guess, how useful such editor would be? 2) Coordinate system transformations (the draw:transform attribute) do not nest. (Don't they?) The OOspec seems to disallow draw:g elements carrying a draw:transform attribute. At least, I couldn't prove they do by Ctrl-f-ing though the spec. (Is there a version of the spec that has cross-referencing in the defined Schema names?) Therefore, the OOdraw coordinate system is flat. Only some basic shapes (exactly draw:page-thumbnail, draw:custom-shape, office:annotation, draw:rect, draw:line, draw:polyline, draw:polygon, draw:regular-polygon, draw:path, draw:circle, draw:ellipse, draw:connector, draw:caption, draw:measure, draw:control) might have a transformation attribute, which only controls the transformation of the shapes own points. In short, the problem is the same as with the symbols above. Nested transformations in a SVG image must be flattened blowing up the file with transformation attributes and removing structure. 3) SVG graphics may be CSS-styled, while OOdraw graphics have their own styling mechanism. The problem of transforming structure-sensitive CSSs into a useful small amount of concrete sensible-named OOdraw styles looks like a challenge. 4) OOdraw does nothing know about clipping. (Doesn't it?) This deficiency can be observed in OOdraw itself. An usual workaround is to draw "white" (or whatever the background is) shapes above the parts of the image one wants to clip away. But this workaround is not applicable to an automatic transformation, since this transformation would have to know the size of the clipped part, and it must make sure not to over-paint some other unrelated parts of the drawing. 5) Markers. While SVG allows the definition of arbitrary complex marker elements for line endings, OOdraw restricts markers to simple paths. The question here again is what to do with SVG markers. They cannot be converted to OOdraw markers, but they also cannot be inlined, because of the missing clipping feature. I think there are more issues - I started writing this with two in mind and found more each time looking more deeply into both specs. Without doubt, there is a bi-simulation between SVG and OOdraw, but there is nothing close to a conversion / bijection. In my opinion, the only way to do the SVG "import" correctly, is to take a full-featured SVG rendering engine and render into OOdraw primitives instead of those of the graphics card. Of cause, this is not what people expect from SVG import, since all structure other than grouping, which was present in SVG, is completely removed. The attached filter svg2draw almost goes the direction of partially rendering SVG into OOdraw primitives. If not impossible, writing a SVG rendering engine in XSL(T) is at least not easy - and pretty useless. The optimal solution in my opinion would be to include a third-party SVG rendering engine (batik?) into OOoffice and let people include their SVG images unmodified into their graphics and texts. This is the best solution, because for non-trivial SVG images, the results that can be expected from a conversion of SVG into a native OOdraw graphic must be almost unusable for anything other than displaying (e.g. editing). Therefore, the best way of preventing people from destroying their SVG images by "importing" them into OOoffice is not to include an SVG import filter at all. Since the conclusion of best closing this issue and not including an SVG import filter into OOoffice was found while writing, the statement at the beginning is relative. But I'll at least provide an "improved" version of the svg2draw filter, if I'm convinced that it does reasonable things for simple SVGs. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
