SVG does not display correctly as an Image

[bytter@…]

When using an SVG file in an Image tag, it is not correctly displayed (at least not under Firefox 1.5 or IE 7). SVG files should probably be outputed as an <object> tag (standards compliant) or as an <embed> tag.

[anonymous]

Having an option to automatically rasterize attached SVG images (or not) would be nice too. Although always delivering SVG files would be the perfect scenario, I see it adequate only when using trac on an intranet context. On the Web, there are still too many browsers that can't handle SVG properly.

[Christian Boos]

One could write a IContentConverter plugin for that, though that API is not yet finalized. So I'm keeping the ticket opened in order to keep it as a requirement when finalizing the API.

Related to #3332.

[Emmanuel Blot]

Replying to cboos:

One could write a IContentConverter plugin for that, though that API is not yet finalized. So I'm keeping the ticket opened in order to keep it as a requirement when finalizing the API.

Related to #3332.

The rasterizing feature should be implemented in a plugin, you're right. It's a complex task which requires external, heavy tool(s), that is other dependencies. Plus it's usually quite difficult to handle some graphic items such as characters (font issues).
I had some very bad times with the ​th:wiki:GraphvizPlugin (due to the rasterizer, not to the plugin) and I've never been able to produce the expected results, not mentioning the dependency nightmare of librsvg.

[Christian Boos]

Replying to eblot:

not mentioning the dependency nightmare of librsvg.

[OT] I had better luck taking the cairo route for making dot produce antialiased png, though having to compile half of Gnome to reach that point could be described as a nightmare as well ;-) (however, following the Linux From Scratch recipes, that was manageable, only long…)

[anonymous]

why not use <object> for all images, SVG included?

[rasmus.olsen@…]

I agree, using <object> instead of <img> would be the most foolproof method. ​http://www.w3.org/TR/REC-html40/struct/objects.html

[Marcus Lindblom <macke@…>]

SVG works reasoanbly well now. Would this be hard to fix?

[Thomas Klein <t.klein@…>]

This ticket is 3 years old now. Nowadays, most browsers can render SVG sufficiently.
Thus, I guess many administrators of trac installations would choose to allow plain SVG images into wiki/ticket markup - just the same way you can include JPEG & PNG (this would obsolete ​http://trac-hacks.org/wiki/TracImageSvgMacro)

[Christian Boos]

Well, actually you can directly point to an SVG file in the Image macro, as most recent browsers indeed support rendering "static" SVG in <img> elements.

Using <embed> as the above plugin does has some security implications (see the links cited ticket:9689#comment:6), but we might eventually add a separate Embed macro, probably as an optional component.

Closing in favor of #9689.

[ted]

I currently use a homegrown automatic feedback grading system for running a data structures class. After students check in their programs, they currently visit a website to see analysis of their submission, with graphviz output in SVG. I planned on running it as a post-commit hook that would generate a trac ticket, but trac keeps the inline SVG that is generated on the fly as part of the page from properly showing. I was surprised that trac can't do it, as you should only need to conform to HTML5 with the correct doctype and allow the svg element to pass through to the browser unmodified. Surely this can be enabled. Is this not a reasonable expectation these days? I'd like to use this in class by January… earlier and I would be able to set up and test first.