create new tag
, view all tags

Archive of DirectedGraphPluginDev

Submitted plugin; this plugin could be more useful with additional dot options for creating graphs. Currently it creates only png files.

-- ColeBeck - 25 Mar 2005

Great! I really welcome its arrival, I've wanted this functionality for years!

-- MartinCleaver - 26 Mar 2005

Cole, thank you very much for sharing this Plugin with the TWikiCommunity smile

I made some minor edits to the Plugins topic, and added a sample screenshot for illustration. You can take this back into the next Plugin release if you wish.

Are the TWiki:Plugins/Benchmark really 100% or is this a guess?

-- PeterThoeny - 26 Mar 2005

There is no pub dir in the distribution and no thus webfonts bundled...

-- MartinCleaver - 26 Mar 2005

This creates WebDOTPlugin functionality...

-- MartinCleaver - 26 Mar 2005

Peter, I'm not sure how to obtain the benchmark for this plugin. If the graph hasn't been generated, running the benchmark will not generate the graph. If the graph has been generated, the plugin won't try to regenerate it, so nothing will happen. So the test will always report 100%, but I have no idea what the real result should be.

Martin, if the webfonts are zipped with the attachment, the size will be greater than 1 MB. I can't attach files this large, so I just provided a link to the fonts instead. If I can be given permission to attach larger files, I would gladly create a new distribution.

-- ColeBeck - 28 Mar 2005

The plugin only runs "dot". With a rather trivial change, it can run "neato", etc. as well (using <neato> tags, etc.). Another useful feature is to smooth-scale the image.

Something like:

  $command=system("/usr/bin/$prog -Tpng /tmp/foo.dot$$
        | pngtopnm | pnmscale 0.5
        | pnmtopng > $path/graph$hash_code.png");

of course, this introduces additional dependencies.

-- WarwickAllison - 30 Mar 2005

The PluginBenchmarks topic has the details on how to measure the performance. Even if the Plugin does nothing, discovering, compiling and initializing a Plugin has some performance impact, typically in the one percent range.

-- PeterThoeny - 30 Mar 2005

Very useful plugin! It throws an error when creating a graph in a web that has had no attachments yet (i.e. there is no "Webname"-dir in pub). The following construct can replace the one that is in the plugin, preventing the error message.

    # Create topic directory "pub/$web/$topic" if needed
    my $dir = TWiki::Func::getPubDir() . "/$web/$topic";
    unless( -e "$dir" ) {
        umask( 002 );
        mkpath($dir, 0, 0755) or return "<noc>DirectedGraph Error: *folder $dir could not be created*";

I have uploaded a patched version of DirectedGraphPlugin.pm to this topic, which has support for <neato> syntax as well (ugly cut'n'paste style hack :-)), and Warwicks smoothscale trick.

-- SteffenPoulsen - 05 Apr 2005

Steffen's patch fixes another bug. The unpatched plugin assumed that the pub directory was always at ../pub off of the working directory. This wasn't always the case even when you use the standard TWiki directory structure.

-- MichaelMcDougall - 06 Apr 2005

I have made a new patch against v1.0 which adds support for clientside maps - makes the plugin even more useful IMHO (take care if you are smoothscaling though, the maps are only valid in 1:1 :-)). Example dot syntax:

digraph G {
  InitialState [URL="InitialState"];
  NewState [URL="NewState"];
  InitialState -> NewState [URL="TheClickableEdge", label="TheClickableEdge"]

BTW: Did anybody checkout the graphviz gallery? - pretty cool stuff you can do with graphviz ..

To support all the of dot utilities (dot, neaty, twopi, circo, fdp + more?), I was thinking we might be better off by inventing ourselves a %GRAPHVIZBEGIN{utility="dot", output="png", smoothscale="off" (or e.g "0.5"),  paramx="valuex"}% / %GRAPHVIZEND% syntax, allowing us to direct the graph to either of the utilities, sending them parameters as needed? I guess inspiration for parameters can be found in http://search.cpan.org/~lbrocard/GraphViz-2.02/lib/GraphViz.pm. - Default would be the setting with the lowest number of dependicies on the envorinment.


-- SteffenPoulsen - 10 Apr 2005

Thanks for the patch Steffen. I agree that it would be better to have a graphviz plugin that supports all of its utilities. I am mildly concerned about security problems popping up with additional features, especially user parameters, but I'm sure there's a safe way to implement this.

-- ColeBeck - 11 Apr 2005

Yep, that's a point to bear in mind, the user parameters. http://www.enyo.de/fw/security/notes/twiki-robustness.html has some hints to increase robustness.

I might find some time at a later stage to implement the %GRAPHVIZBEGIN{...}% syntax, I believe it's the right way to proceed.

-- SteffenPoulsen - 11 Apr 2005

From http://www.linuxarkivet.se/howto/FDU/truetype.html:

You can also get an RPM of WebFonts that contains some of the MS Web fonts from ftp://ftp.rpmfind.net/linux/contrib/noarch/noarch/webfonts-1-3.noarch.rpm. This has enough basic fonts to keep Mozilla and other web browsers happy. Something similar for Debian is http://packages.debian.org/stable/graphics/msttcorefonts . This does not include the actual fonts, but facilitates the installation.

-- MartinCleaver - 12 Apr 2005

I'd like to see support of cmaps. It'd be pretty useful to be able to hyperlink to wiki pages from elements in the graph.

-- MichaelOkincha - 13 Apr 2005

Michael, I don't know if Cole will release a new version with cmap support, but you can use the patch I have attached for now (see above). You're right - does a world of difference with a bit of cmap :-).

-- SteffenPoulsen - 13 Apr 2005

I've released a new version the includes Steffen's bug fix and allows users to create cmaps. Included in the code was Warrick's smooth-scaling suggestion, but it is commented out, as to avoid the new dependency. Thanks for the suggestions. Neato would be easy to add, but I think it is better suited in a generic graphviz plugin.

-- ColeBeck - 13 Apr 2005

It is probably a good idea to just have a GraphVizPlugin... how different would a generic version be?

-- MartinCleaver - 14 Apr 2005

I finally got around to installing this!

I get an error with the simplest possible graph:



And the same error on the test page: http://cleaver.org/TWiki/DirectedGraphPlugin

I've got the last official version installed, and http://cleaver.org/TWiki/InstalledPlugins did not return any issue so I assume its installed ok.

I would appreciate any advice.

Thanks. M.

-- MartinCleaver - 16 Apr 2005

You need the digraph opening line before the graph syntax is OK in TestTopic6 - but it seems there is an error with your setup regarding dot. You may need to debug a bit, e.g. remove the unlink statements in the file, and try to run the dot procedure "manually", seeing what exactly dot is complaining about. My guess is your graphviz installation (not the plugin) is not OK in some way.

-- SteffenPoulsen - 17 Apr 2005

A quick examination of the code revealed that all paths to graphviz are hardcoded... and I installed it under my directory smile

Will have a go at making this configurable tonight.

-- MartinCleaver - 18 Apr 2005

Ok. It worked for me once I'd changed the paths to point at my local 'dot' installation.

It said please feel free to modify so I uploaded over the old one. I used the latest on the plugin topic as it is not in CVS.

Doing this made me think that PluginConfigFiles should be defaulted in a separate overridable file.

This plugin ought use the sandbox feature when it is ported to Dakar.

I'm glad it all seems to work!

-- MartinCleaver - 19 Apr 2005

I installed this on my install at http://testwiki.mrjc.com/twiki/bin/view/TWiki/DirectedGraphPlugin - What should I do to make the test cases look exactly the same as the examples? e.g. The widths of the nodes look different.

-- MartinCleaver - 19 Apr 2005

I think it must be a font problem. How does it look if you generate the files yourself? What is the sandbox feature that you refer to?

-- ColeBeck - 20 Apr 2005

Here's a security patch fixing http://twiki.org/cgi-bin/view/Codev/UncoordinatedSecurityAlert23Feb2005 here.

-- MichaelDaum - 26 Apr 2005

Doesn't this break the plugin on Dakar? (readFromProcess has moved out of TWikiDotPm)

-- FranzJosefSilli - 26 Apr 2005

Well, it certainly doesn't work for me with TWiki version 2 Sep 2004, Rev 1742, since readFromProcess can't be found.

On the other hand, the 1.2 version of DirectedGraphPlugin doesn't work (for me) without this patch either. As near as I can tell, I can't run commands using system(...) as I get back an exit code '11'.

Running the dot command manually, using the exact syntax as given to the system() call works just fine.

This must be a problem with my apache set up, but I can't see what it is. Anyone seen this?


-- SteveWampler - 22 Jun 2005

added .zip to CVS (not the patches, unless they have already been rolled into the .zip)

-- WillNorris - 27 Jun 2005

I've been having problems with the cmap functionality <dot map=1> ... </dot>

TWiki displays the dot sourcecode 'raw' in the browser, and a nonclickable image. Something like:

digraph cmapx { BBC [URL="http://www.bbc.co.uk/"]; BBCRadio4 [URL="http://www.bbc.co.uk/radio4/"]; BBC -> BBCRadio4; label="CMap Example"; }


The image is rendered correctly but is not clickable.

After some digging in DirectedGraphPlugin.pm I discovered the following bugs:

  • When writing an imagemap, tries to call dot with output format dot -Tcmapx .... The version of graphviz (1.9) I am using does not support -Tcmapx. (could it be a typo?)
    • replace cmapx with cmap thoughout
  • The rendered html does not include a <map name="..."> ... </map> section, required to enclose the imagemap <area> tags
    • added <map name="..."> ... </map> tags where necessary

This patch

gets it all working for me.

Now, I wonder how to extend this fine plugin to display a complete map of a web...

-- MagnusLewisSmith - 30 Jun 2005

-- MikaelOlenfalk - 10 Aug 2005

I'm having the same issue as SteveWampler, any ideas?

-- ThomasMatelich - 14 Oct 2005

I have integrated areamap.patch to the plugin for Dakar.

-- JoanTouzet - 24 Oct 2005

Like SteveWampler above I cannot get the plugin to run in Dakar. Same: "Undefined subroutine &TWiki::readFromProcess called" problem. Please tell me if this is workable/fixable and how. Thank You.

-- StephenHurrell - 25 Nov 2005

For the Dakar version, be sure to grab the .zip file from TWiki:Plugins.TWiki or download from SVN. That should solve the readFromProcess problem you are having.

-- ScottHoge - 25 Nov 2005

Does the latest version for Dakar also run on Cairo? This is important since many TWiki installations lag one or two versions behind the latest production release. Plugins that use undocumented Cairo funtions can be made clean with conditional code, see SharedCodeDev#CondCode.

-- PeterThoeny - 25 Nov 2005

I think we had the same problem as SteveWampler. Have twiki installed on windows. Changed the cmd variable in the perl code to include the full path in windows format to the dot.exe. Also changed the location of the tmpFile variable to be placed into the pub directory just to avoid any folder permission problems. After that it worked fine.

Still can't get the colorschemes to work though. Anyone have experience with that?

-- MarioDiCaro - 05 Jan 2006

We're running TWiki release 4.0.1. TWiki::Store doesn't appear to have the readFile subroutine required by this plugin. Has anyone else encountered this error? (Undefined subroutine &TWiki::Store::readFile called)

-- JohnWright - 23 Mar 2006

To the Plugin maintainer: This Plugin does not work in TWiki 4.0. Please consider upgrading this Plugin so that it runs on Cairo and Dakar codebase. HandlingCairoDakarPluginDifferences has more.

-- PeterThoeny - 23 Mar 2006

The version in SVN has been Twiki 4.0.x and Cairo compatible for a while. I've updated the plugin topic to match SVN.

-- ScottHoge - 24 Mar 2006

cool! Cool!

-- PeterThoeny - 25 Mar 2006

Yes, we're now successfully using the plugin within TWiki release 4.0.1! Thanks.

-- JohnWright - 29 Mar 2006

With Twiki 4.0.1, I see a lot of attachments generated by the DirectedGraphPlugin. Is it possible to hide them? Because of that, the real attachments are bit lost in the middle of the PNG/MAP attachments.

-- PatrickValsecchi - 30 Mar 2006

OK, I found a fix. You can add the following somewhere near the end of the handleDot function:

TWiki::Func::saveAttachment($web, $topic, "graph$hash_code.png", {comment=>'Attachment for DOT graph', hide=>1, dontlog=>1});

And the same for the map, if there is one.

-- PatrickValsecchi - 30 Mar 2006

Topic revision: r1 - 2006-04-12 - PeterThoeny
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.