Hallo Thomas,

thank you for your answer.
Indeed our current solution uses a derived Graphics2D (and also bridges, 
graphiccontext, paintserver, etc.), but the transforming result is not very 
satisfying: all entities are drawn as polylines. Even text elements are 
outlined and then transformed to polylines. This looks awful, and additionally 
the dxf file size grows unnecessarily.
For the moment I can't really say why this happens, debugging in the batik's 
deep is difficult for me. So my second try was to "manually" get the entities 
and draw them (which led to my first  question). But maybe we can narrow down 
the original problem in another thread.

Kind Regards

Michael


Von: DeWeese Thomas [mailto:thomas.dewe...@gmail.com] 
Gesendet: Mittwoch, 24. Oktober 2012 01:52
An: batik-users@xmlgraphics.apache.org
Betreff: Re: How to resolve SVGOMUseElement fragments?

Hi Michael,
   The easiest way to convert the SVG to DXF would be to track down a DXF 
Graphics2D implementation and simply have the SVG document draw it's self to 
that DXF Graphics2D.

    That said if you really want to do this you need to use some stuff that 
isn't part of the standard XML DOM to access the Use elements.  In Batik there 
is a special element SVGOMUseElement and SVGOMUseShadowRoot.
You can get from the SVGOMUseElement to the SVGOMUseShadowRoot with the 
getCSSFirstChild which lets you get into the use element's shadow element tree.

    Thomas


On Oct 17, 2012, at 6:04 AM, michael.osterh...@emerson.com wrote:

> Hallo,
> 
> I'm very new to batik, and I spent several hours with Google to find a 
> solution for my problem, but without success.
> I'm trying to parse a SVG which uses several "use" tags with "xlink:href". 
> The goal is to transform the svg into dxf format. The "parent" SVG can 
> consist of many use-tags, that address external SVG files with fragments (#):
> 
> <svg>
>       ...
>       <use xlink:href="file:/C:/files/mySVG_1.SVG#Fragment_1" x="0" y="0"/>
>       <use xlink:href="file:/C:/files/mySVG_2.SVG#Fragment_2" x="0" y="0"/>
>       ...
> </svg>
> 
> 
> The external files themselves consist of several group-tags, that can be 
> addressed by internal fragments again, e. g. "mySVG_1.SVG":
> 
> 
> <svg>
>       ...
>       <g id=" Fragment_1" >
>               <use xmlns:xlink="http://www.w3.org/1999/xlink"; 
> xlink:href="#internalFragment_1"/>
>               <use xmlns:xlink="http://www.w3.org/1999/xlink"; 
> xlink:href="#internalFragment_2"/>
>       </g>
>       ...
>       <g id="internalFragment_1" >
>               <circle cx="491.5" cy="130" r="12.5" />    
>               ...
>               <path d="M 477 210 L 513 210 L 513 50 L 477 50  z" />
>               ...
>       </g>
>       <g id="internalFragment_2" >
>               ...
>       </g>
>       ...
> </svg>
> 
> 
> What I need is the "primitives" of the "internalFragment_1" (circles, paths, 
> rectangles, etc.) to pass them to the appropriate dxf-methods.
> In my SVG-parsing code I can detect the "SVGOMUseElement". I "manually" load 
> the external SVG (e. g. "mySVG_1.SVG") and recursively call my parsing method 
> with it:
> 
> void myTransform(Document doc, dxfContext);
> ...
> else if (node instanceof SVGOMUseElement)
> {
>       Document innerDoc = loadDocument(XLinkSupport.getXLinkHref((Element) 
> n));
>       if (innerDoc != null)
>       {
>               myTransform(innerDoc, dxfContext);
>       }
>       else
>       {
>               //if loadDocument (my own method) returns null, the link target 
> was not an external file but a simple internal fragment
>               //what to do here to resolve the internalFragments down to the 
> primitives?      
>       }
> ...
> 
> 
> But when I get the internal SVGOMUseElement addressed by "Fragment_1" I don't 
> know how to resolve the content of the addressed "internalFragment_1". There 
> are no childNodes or a shadowtree or something like that. 
> What is the right way to resolve the internal fragment of a SVG to get its' 
> primitives?
> Thank you very much for your help.
> 
> Kind Regards.
> 
> Michael
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org

Reply via email to