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 xsltprocOn 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
signature.asc
Description: This is a digitally signed message part
_______________________________________________ dia-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/dia-list FAQ at http://live.gnome.org/Dia/Faq Main page at http://live.gnome.org/Dia
