|
|
Copyright © 2009–2010 Arndt Roger Schneider |
Table of Contents
»tkpCode« is a DOM-tree parser. »tkpCode« parses a SVG document, represented by a DOM-tree and generates TkPath 3.0 Tcl-Code from it.
tkpCode is the complement to svgCode.
Required DOM operations: - firstChild - nodeName (perhaps also nodeType) - nextSibling - attribute - getAttribute - root - descendant
The DOM tree variable is located inside the dumper namespace as »_doc«; again the same as # in svgDumper.
⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ Side note on »overflow«: overflow must be handled by creating child canvas windows whenever the value is set to hidden. The SVG, pattern or marker element establishes a rectangular clipping path. Unfortunately scroll does not seem to work right away...
⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ ⋅ Storage needed for: Images, Name is taken from SVG (ID), or when it has no ID a new ID is generated directly where it is being used, no need to keep track of images without an ID ? Well if an image is referenced by a filename the file name without path is being used as the image name. No need to keep image names!
Storage need for gradients ? Definitely yes the gradient names are being lost by TkPath.
Left to the DOM-tree! The tkpDumper will access the DOM-tree directly –dumper owns the DOM-tree anyway.
See how to handle different namespaces ? Example sodipodi and Inkscape inject parts from their own customization into the SVG. Either reuse this settings and or ignore them in a specific way... A probable way is to watch for the namespace identifier and or to parse all the data and simply let the alien stuff slip through .. which is the current method.
TkPath and gradients.
The created gradients will be OK when the SVG was generated from the same TkPath version! it is also OK when a TkPath 0.3 view is back ported to TkPath 0.2.4.
Gradients can be created inside of SVG on any level, the gradients inside TkPath are either global (0.2) or part of the creating canvas window.
This is an unlikely issue, view SVG application do work well with multiple viewports! Must be fixed inside of TkPath.
A workaround for this would contain a search for the viewport of an encountered gradient –its usage place– and then compare it with the current viewport.
tref, sub and super: are implemented. sub and super do require using font measure –which I rather prefer not to use. font metrics are also calculated for sub and super, hence Tk is required too.
Mask, Font, Pattern, Marker, are analyzed, but there is no implementation for them. Not possible with TkPath 0.3. - pattern could be partly implemented by Tk Canvas -stipple. Or –when it is an image– by Zinc -tile. - Markers, may originate from arrows either inside Tk Canvas or Zinc.
Additional (future) Elements: Desc, ClipPath, Symbol, Title, Switch. - clipPath can be implemented by Zinc -clip. Requires a enclosing group.
Dependencies
tdom
Tk
|
|
Copyright © 2009–2010 Arndt Roger Schneider |