GNOME Bugzilla – Bug 499544
Added support for SVG graphics with dot
Last modified: 2011-01-04 12:48:27 UTC
Hello, I've created a patch which adds support for generating Scaleable Vector Graphics instead of bitmaps (for HTML output). Most today's browsers have at least limited support für rendering svg graphics. I got the best results with Opera, Firefox is nearly Ok, Konqueror has some work left... SVG graphics are included with the <object></object> tag instead of <img>. I got most information from SELFHTML (german only): http://de.selfhtml.org/html/multimedia/objekte.htm#datendateien For browsers which doens't support rendering SVG it's possible to show an alternative content (e.g. a png graphic). Thus my patch creates additional png (fixed) graphics when the user selects svg. Patch description (generated with 'svn diff'): - config.l: o Added 'svg' item for DOT_IMAGE_FORMAT - dot.h o Added prototype for getPngImageSize() (see open issues) - dot.cpp o Implemented getPngImageSize() (see open issues) o Generate an additional png file if the user selected svg format o Include both files as mentioned in the above tutorial - htmlvisitor.cpp: o Generate an additional png file if the user selected svg format o Include both files as mentioned in the above tutorial I've tried to adopt the existing coding style as good as possible. There should be no additional changes than those mentioned above. If the user doesn't select the svg format, the patch shouldn't have any effects. Open issues: - Image size of the SVG graphics It's not very straightforward to generate an svg file with the same (displayed) image size compared to an equal bitmap file. For reasons I don't understand the dot tool uses different sizes for svg and png graphics. I've tried to change this by setting DPI to 96 in dot but the resulting graphic was not rendered correctly in most of my browsers. So I've decided to get the destination size from the png file (which is also created) and to scale the svg to this value. This possibly strange way produced the most acceptable results. Additionally this size is multiplied with the factor 1.04 because otherwise Firefox sometimes displays scrollbars for small images and Konqueror cuts the image at the right and bottom edge. - Hyperlinks in the SVG graphics For resons I don't know (perhaps a bug), all hyperlinks in the doxygen generated dot files start with a '$' character. This char is also present in the generated map file. I've never seen this before but it seems that it doesn't harm. For svg graphics at least some browsers don't use the map definition, they get information about hyperlinks directly from the svg file. Dot also includes the $ from the dot file here. At least in this case, my browsers failed to follow the link until I removed the $ char. Maybe it would be the best to remove it at all. - Fonts in SVG graphics: SVG graphics generated by dot includes a font-family attribute with the value "FreeSans.ttf". This seems to be wrong for all browsers I tested. Afaik it would be the best, to convert the file FreeSans.ttf to a SVG font file http://xml.apache.org/batik/ttf2svg.html and use this external font description inside the SVG graphic: http://svg.tutorial.aptico.de/start3.php?knr=17&kname=SVG%20fonts&uknr=17.3&ukname=Externe%20SVG%20Fonts (german only) I think the second item is more related to graphviz than to doxygen. Perhaps doxygen should put a SVG font definition file in the html output directory and a new option should be added graphviz with allows to include external font definitions in svg graphics. Test report: o Linux - Konqueror: SVG graphics have a white background even if 'bgcolor="transparent"' is defined in the source dot file. Graphics are cropped if not scaled with at least 1.04 as described above. Incorrect fonts are used. - Firefox: Small graphics get a scroll bar if not scaled with at least 1.01. Incorrect fonts are used. - Opera: Graphics are scaled correctly but incorrect fonts are used. Texts inside the graphics can be copied to the clipboard (this is what I would like to see with all browsers). o Windows: - IE7: The alternative PNG files are displayed because no SVG plugin is installed on my machine (this is what I expected). - Firefox: Same result as under Linux - Opera: Same result as under Linux regards Christian
Created attachment 99620 [details] [review] Patch as described in the report
Created attachment 99621 [details] Doxygen documented test file with different sized images
Created attachment 116112 [details] [review] This should fix URI problems. This patch is not complete in the sense that applying this alone won't get you much. What this does is it strips the dollar sign and things to the left from the URL before being passed into dot, which should linkify the nodes correctly.
(In reply to comment #0) > Open issues: > - Hyperlinks in the SVG graphics > For resons I don't know (perhaps a bug), all hyperlinks in the doxygen > generated dot files start with a '$' character. This char is also present in > the generated map file. I've never seen this before but it seems that it > doesn't harm. The patch I just posted should fix this issue. > - Fonts in SVG graphics: > SVG graphics generated by dot includes a font-family attribute with the value > "FreeSans.ttf". This seems to be wrong for all browsers I tested. This is due to the passing in of "FreeSans" as the font-family in the file. I have an open RFE with graphviz to get the font fallback working properly. Passing in a correct font file--and linking it in the output--would probably produce the right results. Also at issue is the fact that graphviz outputs a font-size of 10.00, with no units, which is illegal CSS. I am also in contact with graphviz people to fix this issue as well. > I think the second item is more related to graphviz than to doxygen. Perhaps > doxygen should put a SVG font definition file in the html output directory and > a new option should be added graphviz with allows to include external font > definitions in svg graphics. I believe it can do this, although I haven't checked thoroughly here.
Ping? What is the state of this issue? SVG support would be really a good feature, reducing size of documentation...
I'm sorry but at the moment I'm working on other projects ([1]). There's only little chance that I can continue working on this in the near future. Perhaps somebody else might try... regards Christian [1] http://www.heise.de/ct/projekte/machmit/ctserver/wiki/ctserver4
Hi all, Good news for everyone who has been waiting for SVG support in doxygen: I'm working on it and the first results are very promissing.
Great to hear :-)
(In reply to comment #7) > Hi all, > > Good news for everyone who has been waiting for SVG support in doxygen: > I'm working on it and the first results are very promissing. Be award that the current Doxyfile delivered with the source code produce “SVG” as DOT output format. For some reason this don’t works in the Firefox browser. The code look 100% ok, and the browser can view the generated SVG files, but it don’t works in the content. Regards Poul-Erik.
Hi Poul-Erik, I tested with Firefox mostly, so for me it sure works fine with that browser. Which version of Firefox do you use? (I have 3.6.13)
(In reply to comment #10) > Hi Poul-Erik, > > I tested with Firefox mostly, so for me it sure works fine with that browser. > Which version of Firefox do you use? (I have 3.6.13) I am using Firefox 3.6.13 and I see no graph. According : http://tutorials.jenkov.com/svg/displaying-svg-in-web-browsers.html you must use the "<embed>" insted of <img> tag. I have only tried ones but now I can see the graph.
(In reply to comment #11) > (In reply to comment #10) > > Hi Poul-Erik, > > > > I tested with Firefox mostly, so for me it sure works fine with that browser. > > Which version of Firefox do you use? (I have 3.6.13) > > I am using Firefox 3.6.13 and I see no graph. > According : http://tutorials.jenkov.com/svg/displaying-svg-in-web-browsers.html > you must use the "<embed>" insted of <img> tag. > I have only tried ones but now I can see the graph. But I'm not using the <img> tag! There are 3 ways to embed SVGs, using <embed>, <object>, or <frame>. I use iframe, as that is XHTML compliant and embed isn't. Can you attach a small example (source + config file + html output) that shows the problem you see?
(In reply to comment #12) > (In reply to comment #11) > > (In reply to comment #10) > > > Hi Poul-Erik, > > > > > > I tested with Firefox mostly, so for me it sure works fine with that browser. > > > Which version of Firefox do you use? (I have 3.6.13) > > > > I am using Firefox 3.6.13 and I see no graph. > > According : http://tutorials.jenkov.com/svg/displaying-svg-in-web-browsers.html > > you must use the "<embed>" insted of <img> tag. > > I have only tried ones but now I can see the graph. > > But I'm not using the <img> tag! > There are 3 ways to embed SVGs, using <embed>, <object>, or <frame>. > I use iframe, as that is XHTML compliant and embed isn't. > > Can you attach a small example (source + config file + html output) that shows > the problem you see? This is the output of Doxygen 1.7.2 without dynamic html: <div class="center"><img src="a00346.svg" border="0" usemap="#src_2appl_2sys__state_8c" alt=""/></div> This grapth shows the include files. This is the output of Doxygen 1.7.2 with dynamic html: <!-- startSectionHeader --><div id="dynsection-0" onclick="return toggleVisibility(this)" class="dynheader closed" style="cursor:pointer;"> <img id="dynsection-0-trigger" src="closed.png"/> Include dependency graph for sys_state.c:<!-- endSectionHeader --></div> <!-- startSectionSummary --><div id="dynsection-0-summary" class="dynsummary" style="display:block;"> <!-- endSectionSummary --></div> <!-- startSectionContent --><div id="dynsection-0-content" class="dyncontent" style="display:none;"> <div class="center"><img src="a00346.svg" border="0" usemap="#src_2appl_2sys__state_8c" alt=""/></div> I have only tried the to replace the <img> with the <emped> tag in the version without dynamic html. best regards Poul-Erik.
(In reply to comment #13) > This is the output of Doxygen 1.7.2 without dynamic html: > > <div class="center"><img src="a00346.svg" border="0" > usemap="#src_2appl_2sys__state_8c" alt=""/></div> > Ah, you are using the official 1.7.2 release... Version 1.7.2 doesn't have SVN support. It will be introduced in 1.7.3 (and can already be tested if you download and compile the latest snapshot from subversion).
(In reply to comment #14) > (In reply to comment #13) > > > This is the output of Doxygen 1.7.2 without dynamic html: > > > > <div class="center"><img src="a00346.svg" border="0" > > usemap="#src_2appl_2sys__state_8c" alt=""/></div> > > > > Ah, you are using the official 1.7.2 release... > > Version 1.7.2 doesn't have SVN support. It will be introduced in 1.7.3 (and can > already be tested if you download and compile the latest snapshot from > subversion). You are right. In the current version 1.7.2-20101224 in snv the SVG works OK. My orgiale commens was regarding the old source released for version 1.7.2. You should update the commen in Doxyfile : now it look like this: # The DOT_IMAGE_FORMAT tag can be used to set the image format of the images # generated by dot. Possible values are png, jpg, or gif. # If left blank png will be used. DOT_IMAGE_FORMAT = png PS. I know this isn't the right place but my tree view (left frame) don't work in this svn version 1.7.2-20101224. best regards Poul-Erik.
This bug was previously marked ASSIGNED, which means it should be fixed in doxygen version 1.7.3. Please verify if this is indeed the case. Reopen the bug if you think it is not fixed and please include any additional information that you think can be relevant.
(In reply to comment #16) > This bug was previously marked ASSIGNED, which means it should be fixed in > doxygen version 1.7.3. Please verify if this is indeed the case. Reopen the > bug if you think it is not fixed and please include any additional information > that you think can be relevant. Checked OK in 1.7.3