- 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
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