Totally possible…
HTML:
You are dependent on browser support for SVG if you want to embed SVG into your HTML pages. Here's a page that tries to list support in a meaningful way: http://caniuse.com/#cats=SVG
That means either assuming the people reading your content have a browser capable of natively rendering SVG or that they install a plug-in that can do that. See attached screen capture of the current version of FireFox (without plug-in). The content being displayed is standard output from the DITA OT 1.4.2.1 (the version that ships with XMetaL Author Enterprise 6.0) without any changes. See attached DITA_and_SVG_sample.zip (link after this post) for the example used to generate the FireFox screen capture.
If you can't count on the people reading your content to meet those requirements then you need to select an image format that most browsers can support. All browsers capable of rendering images can probably render JPG and GIF. Most can also render PNG (a browser has to be pretty old not to support PNG). So, you then need to decide when to transform your SVG into one of these supported formats.
1) Modify the DITA OT to generate alternate image types during output generation and linking to them instead (potentially a lot of work).
2) Or perform a batch conversion from time to time that converts from SVG to a supported format. This might be easier as there are many tools available that will do this.
3) Or have the person that creates your SVG provide you with alternative forms of the image that are in a supported format. They might do this when they save the SVG as most graphics applications allow saving to multiple forms.
For #1 you might have someone hook Apache Batik up (or a similar tool) so that it transforms your SVG files while the DITA OT is producing output.
For #2 or #3 you could always link to the alternate form (probably JPG, PNG or GIF) in your DITA elements (and never include references to the SVG files at all). Or if you wish to still use SVG for some outputs for some reason then you could use conditional text something like the following:
In this case when you produce output you would need to use the conditional text feature, or provide a DITAVAL file with pre-configured settings for each output type you wish to produce (those that support SVG would use a DITAVAL with otherprops=”imgSVG” and those that do not would use the other one).
PDF:
The PDF standard itself does not support embedding SVG inside PDF files. RenderX XEP has the ability to transform SVG into an appropriate form and will embed that into PDF files and it will do this automatically if you reference an SVG file in your DITA content. This means you must be producing PDF using a deliverable type that uses RenderX XEP (“XMetaL Enhanced PDF via RenderX XEP” for example). The missing piece (which is why you may not see such images embedded in your PDF even if using this deliverable) is that the DITA OT only copies files it considers to be “images” into the appropriate folder for RenderX XEP to find them and these image types may not include SVG. To work around this you can try the following:
1) Include an @href reference to your SVG image in an tag (see attached DITA_and_SVG_sample.zip — link after this post)
2) Generate output using the deliverable “XMetaL Enhanced PDF via RenderX XEP”.
3) Locate the folder where the PDF file was generated in and copy your SVG images into that folder into the appropriate subfolder (if any). The folder structure should match that of the original @href value (to simplify things to start with you may wish to avoid using subfolders).
4) Generate output once more. This time RenderX will locate your SVG images, transform and embed them into the PDF. Note that this can add to the length of time needed to generate a PDF compared to the same DITA topic referencing a JPG and I assume that is dependent on the complexity of the SVG being transformed.
If you still don't see images in your PDF check that the path from the XML file to the original SVG is the same relative path in the PDF output folder (the path from the PDF to the SVG). If you search the topic.fo file in the zip I have attached for “.svg” it may become clearer what the path should be (the path is actually relative to this .fo file). See following page as well to check that the SVG image itself is supported by XEP as there are some limits as to what it can handle: http://www.renderx.com/reference.html#SVG
