xmlgraphics-batik-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From thomas.dewe...@kodak.com
Subject RE: Need Help Copying SVG from a DOM Document into a SVGOMDocument
Date Thu, 10 Nov 2005 10:37:52 GMT
Hi Philip,

"Fennell, Philip" <philip.fennell@hp.com> wrote on 11/10/2005 03:18:13 AM:

> Are you using SVG's metadata element to encapsulate your metadata? That
> should render your metadata mark-up invisible to Batik, regardless of
> namespaces.

   This is wrong.  The Batik SVG DOM will refuse to create an element
in the SVG namespace unless it is part of the SVG specification.  The
metadata element is mostly for humans not for User Agents, namespaces
work much better for User Agents.

> Hi Kevin,
> 
>    The summary,  you need to use XML namespaces.
> 
> "Kevin Whittington" <Kevin.Whittington@catalinamarketing.com> wrote on
> 11/09/2005 12:20:02 PM:
> 
> > I am in need of assistance.  I am currently working on a program that
> reads an
> > XML document that is mostly SVG but contains some other tags as well
> that 
> > represents some metadata specific to my business.  This program reads
> through 
> > the XML document and replaces the metadata tags with pure SVG.  The 
> > now
> "pure 
> > SVG" document is then given to a TranscoderInput and ultimately 
> > printed
> via a 
> > PrintTranscoder.
> > In order to read the XML/SVG hybrid document, I use a standard DOM
> Document 
> > created via a DocumentBuilder because an SVGOMDocument fails to parse
> the non-
> > SVG metadata tags that are included in the document). 
> 
>    The best solution to this would be to place your non-SVG elements in
> a custom namespace.  This is very simple and would allow your document
> to be parsed as an SVG document from the start (saving all this coping
> non-sense).
> 
> I would suggest that you make your root svg element look something like:
> 
>         <svg [ normal attrs ]
>                 xmlns="http://www.w3.org/2000/svg" 
>                 xmlns:xlink="http://www.w3.org/1999/xlink" 
>  xmlns:catalina="http://catalinamarketing.com/something/meaningful">
> 
> Then in your document you can simply use a prefix for all your custom
> elements:
> 
>         <catalina:data foo="x" bar="y"/>
> 
> > Once the metadata tags
> > are replaced within the XML/SVG document, the document contains only
> pure SVG 
> > but still exists within memory as the plain old DOM Document (I'll 
> > call
> this 
> > Document A).
> 
>    During the replacement (if you go this route you can even leave the
> custom tags Batik will ignore them, and all their children - so don't
> add SVG as a child of a custom tag) make sure you use the namespace
> aware methods (i.e. use getElementsByTagNameNS instead of
> getElementsByTagName).
> 
> > This confounds me so I came up with a temporary solution.  I save the
> SVGOMDocument
> > to disk and then reparse it into a new SVGOMDocument (Document C). 
> > This
> 
> > solution does work and the document prints perfectly as expected. 
> However, 
> > writing to disk is not the solution I want to use.
> > Apparently the nodes within Document B contain enough information to
> correctly
> > write the SVG to disk but not enough information for transcoding.
> 
>    This is typical of namespace issues.  If the document is read as an
> SVG document in Batik 1.6 we 'provided' the SVG namespace decl. so your
> elements were SVG elements.  If it was read by a generic XML parser your
> elements will land in the default namespace.
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
> 


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


Mime
View raw message