Le Wed, Jun 19, 2002, à 08:59:10AM -0700, James Michael DuPont a écrit:
> > (one alternative idea might be to find/modify
> > something to have an EPS->SVG
> > converter.
> That is what pstoedit can do, svg output. :)
[snip]
> >Once the
> > TeX file is converted to SVG, it should be possible
> > to modify the shapes'
> > SVG import routine in order to render by dia.
> Ahh.. you have that?
Yes. Check out objects/custom/shape_info.c/shape_info_load()
(more below).
This is of course not exactly what you want (because it would load a .shape
file, not just an SVG), but it could be tweaked to accept a plain SVG file
and derive a shape out of that.
> > Basically, the TeX object
> > would be a shape whose visual contents depend on the
> > output of a TeX process)
> Cool a create shape on the fly. You might have lots of
> them. I bet one shape per polygon would be good.
The TeX equation would end up being converted into a zillion of elements
inside the display_list member of the ShapeInfo structure (which, at this
point, is used only inside the Custom object). These, together, would
constitue only a single object (of arbitrary visual complexity).
So, basically, here's how I understand this could look like:
* Tex object derives from Element, aggregates a ShapeInfo, has a
string attribute, and a (hidden) SVG document attribute.
* The property page allows to change the string attribute (TeX
source) and has a push-button, which when pressed pipes the source string
into TeX and various other magic things, which result in a temporary SVG
file. The SVG file is parsed through libXML and its tree nested into an
attribute of the TeX object. The SVG tree is also passed through a modified
version of shape_info_load())
* Once a complete ShapeInfo structure has been filled from SVG data,
the TeX object renders the contents of that ShapeInfo (probably scaled to
fit the Element bounding box)
* The ShapeInfo code will probably have to be moved out to lib/ in
order to be available both from the Custom and the TeX objects.
Hopefully this matches what you had in mind...
> Also I would like to ask what do you think about using
> a postgres database backend for your object? Like be
> able to store all the diagrams in a database?
> via Perl::DBD we can hook in any database around.
> Cool huh?
>From a DBA's point of view, probably. From mine, not at all: handling a
Postgres database is totally out of possibility for the average Linux
end-user. Now, keep in mind we also have Win32...
What's wrong with storing a diagram per file?
-- Cyrille
--
Grumpf.