SVG Status

[Keiron Liddle <ke...@aftexsw.com>]

SVG Status
----------

SVG support in FOP.

With the release of the new spec the java bindings have changed, but the
also
compile.


Supported elements
------------------
rect
circle
line
text - tref, tspan
path
polygon
polyline
ellipse
g
svg (inside)
image
use
defs (including referenced items not in defs element)
linearGradient
radialGradient
stop


Supported properties
--------------------
style
 fill
 stroke
 stroke-width
 stroke-dasharray
 stroke-offset
 stroke-linecap
 stroke-linejoin
 stroke-miterlimit
 stop-color
 color
 font
 font-size
 font-family
 font-weight
 font-style
x
y
x1
y1
x2
y2
r
cx
cy
x (list)
y (list)
dx
dy
transform
 rotate
 translate
 scale
 matrix
 skewX
 skewY
d
id
width
height
xlink:href
refX
refY
offset
points
fx
fy

Issues
---------------
* how does scaling work, what origin

TODO
----

1. Support Working Draft 1.0 29 June 2000
Update the dom code to the latest java bindings.
Support all the properties and styling.

2. Continue the separation of svg from the fo code.
- separate properties by name space (the current uncommitted
implementation is too slow, hashtable lookups, strings and casting).
 * addPropertListBuilder to the Driver
 * Driver loads class which calls it to add to the FOTreeBuilder
 * FOTreeBuilder adds the property list to the PropertyListBuilder
 * PropertyListBuilder looks up Property.Maker almost the same as before

- separate the svg rendering from the fo rendering, is this practical?
- allow for content processors to be registered with FOP through
the namespace mechanism. We'd start handling this in
FOTreeBuilder - this is particularly appropriate now
that FOP is SAX2 aware, which means that namespace information is more
conveniently presented.

Issues:
(1) front-end: how does FOP get called?

(2) calling self: have we thought about this? eg. svg documents inside
svg image elements

(3) fo:instream-foreign-graphic: registering content processors with
FOP,
and receiving output in the layout package - stuff known to FOP;

(4) fo:external-graphic: renderers must be available to handle foreign
content.

(5) Renderers: what API will they use? Are we currently exposing our
layout
objects appropriately? Can we support voice? Etc.

3. Implement missing objects.

svg:a
...

4. Make it so that some arbitrary namespace can be converted to (for
example) svg
and then rendered to pdf. This would need a dom created for the
namespace document
then an xslt applied to create the svg document. Need to get around the
specific
element construction.

5. Individual Tasks to do.
* AWT renderer
* fix up the smooth shading, some figures etc are wrong
* mask
* text dy list
* text transform
* text path
* escaping special pdf characters in text
* unknown problem with text rendering??
* clipPath
* filter
* and lots more svg elements...
* arcs in paths
* round edges to rects

* fo:instream-foreign-object
* rationalise the top level SVGArea (fo) and the SVGDocument or root
element

* update documentation

6. This is a long term view of svg (and other namespaces) in fop.
Once the internal structure fully allows the inclusion of arbitrary
namespaces
in the rendering.

Use svg as a useful _default_ for such other spaces. We can
anticipate that most foreign namespaces will result in graphic content;
using SVG as an intermediary is a good fallback.

Two ends of the spectrum:
         - read the complete XML input, identify the namespaces, hold
them
as W3C DOMs and transform (in memory) with namespace-specific XSLT. This

only requires a generic XSLT processor such as Xalan (or possibly a
subset
would do)
         - read the XML input, convert to namespace-specific DOMS and
traverse these with appropriate API these to generate an SVG DOM which
is
then transformed to FO. We could also make a case directly for
transformation into FO in some cases.