Re: wysiwig TeX in dia

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
That is what pstoedit can do, svg output. :)


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?

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]