I just stumbled across the DiaRenderScript plug-in in svn. That seems
rather useful! I have a few questions about it:
1) Why doesn't the plug-in get installed correctly w/ make install?
(gets compiled and ends up in plug-ins/drs/.libs, but not in
$PREFIX/lib/dia, copying it there it works though)
2) the output seems to contain both the diagram structure (in dia
format I guess, but not namespaced) and the rendering information,
which is exactly what I need, but the DTD doesn't say anything about
properties / attributes. Is that valid?
3) The dtd uri http://projects.gnome.org/dia/dia-render-script.dtd gives
404, not so important but spits out lots of warnings from xsltproc
On Wed, 2010-11-10 at 23:32 +0100, Hans Breuer wrote:
At 10.11.2010 09:59, niklas | brueckenschlaeger wrote:Hi, I'm trying to export diagrams to SVG, then styling them with CSS. This doesn't work right now because the SVG carries no semantics (i.e. IDs or classes). Looking at diasvg.py, it seems like in the renderer there's no access to the original semantic objects (UML Class, Association, ...) anymore.Right, the usual renderer interface is pure drawing.Is there maybe a higher point in the API to hook into for implementing this?Only a much higher level, see export-object.py as example. Or codegen.py for something producing more useful output. On the C-level there also is Renderer::draw_object(Object *), but currently there is no way to "overwrite" it from PyDia code. Also missing is the ability to call the base class implmentation, i.e. get the drawing call within the same renderer.
uhm. I only find draw_object(DiaRenderer *, DiaObject *) in diarenderer.c, but that just calls the DrawFunc of that object. But I don't know enough about the dia code to understand how that's helping me.
It would also be fine just to be able to generate extra output, with all the objects in the order they were rendered, then I can post-process that SVG to add the appropriate classes.Although the rendering order is deterministic as in: for layer in data.layers : for o in layer.objects : ... you still would have a hard time to match the rendering calls with the objects
yeah, I figured that would be quite hacky :)
. The best way would be implementing both draw_object parts as outlined above, but that involves some C hacking in the bindings.
no worries, anything to skip python... Thanks for your help! -- niklas
-------- Hans "at" Breuer "dot" Org ----------- Tell me what you need, and I'll tell you how to get along without it. -- Dilbert
Attachment:
signature.asc
Description: This is a digitally signed message part