W3C home > Mailing lists > Public > www-svg@w3.org > July 2009

Re: SVG text flip-invariance

From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
Date: Tue, 7 Jul 2009 16:50:01 +0200
To: tim.edwards@multigig.com, www-svg@w3.org
Message-Id: <200907071650.01908.Dr.O.Hoffmann@gmx.de>
I see, indeed without waiting for future specifications
or implementations (transform="ref(svg) is specified
but not yet widely implemented) - you have a 
problem with this. 
But if you have only 4 discrete rotated possible orientations
and the related 4 mirrored, you can solve the problem
with a brute force method having nine symbols
calculated, one with the drawing and 8 with the 
possible text positions and for presentation you
'only' have to chose the proper text symbol for
the current orientation. This solution is not very
nice or elegant, but at least scalable and works
with old viewers too.

For arbitrary orientations it is more difficult to
reuse the text somehow.

But as for such graphical representations of
functions and data sets it is anyway currently
the best approach to separate the raw data
from the graphical representation completely
to enable others to reuse such data with
another program. I think, neither postscript nor
SVG is very good to reuse the data from the
graphical presentation. For this it is better, 
to have a specific XML-Format understandable
for the manipulation programs. Such data 
could be added additionally to the SVG
output as reusable metadata, others can
extract for further manipulation (this is simple
in current SVG but maybe not trivial in postscript).
This conserves the semantical/technical/specific
meaning of the structures better as a 
graphical representation with graphical
primitives representing not much more than
rectangles, ellipses or paths.
If the manipulation programs can interprete
this specific XML-Format, they can simply
extract it and can generate a new SVG 
after manipulation, including the new data
again as meta information.
For experimental data sets and their
graphical representation I started already
to write such an 'extension'-Format, because 
practically such data cannot be extracted precisely
anymore from a graphical representation,
what is very annoying within scientific publications.
On the other hand it is always possible to reconstruct 
the graphical representation from the raw data.

Of course, for the future such a property to
align text always to one direction relative to
the topmost (or indicatable) viewport would 
be a nice feature. This has to contain
some information about something like the
center point of the local text (attributes x and y?) 
and for the alignment direction. If mirroring might 
be useful too, one needs an additional parameter 
for this.
Received on Tuesday, 7 July 2009 15:00:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:29:40 UTC