Re: applying custom styles to diagrams

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 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:
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
Looking at, 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
Only a much higher level, see as example. Or 
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

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 

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

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