First experience with SVG


about the mentioned problems:

a) text in a box - SVG tiny 1.2 has textArea for this -
unfortunately not available yet in many viewers.
Alternatively one can of course use an own SVG font
within the document to control the size of text
precisely. Unfortunately some viewers still ignore
internal SVG fonts.
Another option is to use foreignObject with XHTML
fragments in it - unfortunately for some viewers
the interpretation of foreignObject is problematic
and interpretation of XHTML within SVG not 
Basically improvement of viewers is required here
for all options, SVG itself provides already good
options to get this work.

b) Origin and orientation of coordinate system - 
yes, this can be a problem for some applications.
Programs like grace for example use the same
method as you mention and I think they use a
matrix transform to get the text unmirrored again.
Could be pretty useful for authors to have access
to origin and orientation of the coordinate system
in a future version of SVG, this should be much
simpler to control for viewers than authors doing
these transforms manually, if there is text as well
inside the document.
- use viewBox instead of invalid notations like translate(0,100%).
Using a viewBox you always know exactly, how many local
units 100% is.
c) rendering order - because this will be presumably
added in future versions of SVG, some tricks are
required now:
Put all relevant elements in the defs element of
the document and reference them with use elements
With declarative animation one can animate the
XLink:href of the use elements to get everything in
the desired order.
If you only want to have an element with mouseover
on top, you can simply add one use element as the
last one in the document and animate the XLink:href of
this to get such an effect (note that there can be a
problem, if elements parents are transformed somehow).


Received on Thursday, 21 June 2012 09:23:20 UTC