Hello! Why do some SVGs work and not others??

[dlemkuil]

I'm an illustrator trying to get my nice SVG graphics to show up in XMetaL author 5.5 so the writers can see them. My drawing program of choice is Arbortext IsoDraw and the writers have the Adobe SVGViewer installed. For some reason, the SVGs exported from IsoDraw only show a small corner of the graphic, whereas, if I open the SVG in Visio 2003 and then resave it as a Visio SVG, the whole graphic is visible in XMetaL. Is this a schema and namespace issue? The IsoDraw SVGs seem to work in other programs. I'm scratching my head...anyone else have these issues with SVG? I really don't want to add another step in my illustration process.

[Derek Read]

(what is described below is valid up to an including XMetaL Author Enterprise 6.0)

What it comes down to is this:

1) We embed Internet Explorer in DITA documents when we encounter an <image> that looks like it is referencing an SVG file (matching on href="*.svg").
2) The script that embeds IE needs to tell IE where the file is (easy enough) and the size because IE must be told how big to draw itself. IE then loads the SVG and handles it with whatever viewer it has installed, if any.
3) In order to tell IE how big to draw itself we have a script that opens the SVG file as XML and parses it to extract the width and height attributes from the <svg> element. If these are not present then the image defaults to 200px square. The way this script is currently written also assumes these values are set in pixels and that they do not specify the units. If the units are specified then this sizing will also fail as no attempts to do unit conversion have been implemented.

So, something like the following will render at the proper size:

Code:

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg width="640" height="480" >

For the following you'll see a 200 x 200 area:

Code:

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg width="640px" height="480px" >

Code:

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<svg width="6.5in" height="5in" >

There are likely possibly many different ways SVG rendering support (in general) can be improved on our side and we're looking into that.

[dlemkuil]

Derek,

Here's the difference in the first few lines of code between Visio and IsoDraw:

Visio

Code:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.0//EN" "http://www.w3.org/TR/2001/REC-SVG-20010904/DTD/svg10.dtd">
<!-- Generated by Microsoft Visio 11.0, SVG Export, v1.0 aedgrr025.svg Standard_x0020_layer -->
<svg xmlns="http://www.w3.org/2000/svg" xmlns:v="http://schemas.microsoft.com/visio/2003/SVGExtensions/" width="6.44933in"
height="5.94327in" viewBox="0 0 464.352 427.915" xml:space="preserve" color-interpolation-filters="sRGB" class="st14">
<v:documentProperties v:langID="1033" v:viewMarkup="false"/>

IsoDraw

Code:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<!-- Generator: Arbortext IsoDraw 7.0 -->
<svg id="Standard_x0020_layer" width="163.813mm" height="150.959mm" viewBox="0 0 163.813 150.959"
 xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
 fill-rule="evenodd" clip-rule="evenodd" stroke="#000000" stroke-linecap="round" fill="none" xml:space="preserve">

With a little testing, we figured out that "inches" work but "millimeters" doesn't. Is this a limitation of the SVG Viewer, XMetaL, the browser, or what?

Thanks for your help,
Dave

[Derek Read]

Sorry, my mistake. When this code was originally written (as a demo for our developers to base the shipping version on) we didn't put any unit conversions in. Our developers have added support for cm and in. The code could be easily extended to handle mm (as that is just cm * 10).

If this was just for your machine then I'm not too worried about showing you how to make this minor improvement. However, it sounds like you need to roll out any change to various other people so that gets a little more worrying. Manually changing files this way means that the product will not cleanly uninstall (you will need to manually remove this particular file later), and an installation repair (via Add or Remove Programs in the Control Panel) will eliminate the "fix". Also, depending on your Windows version and IT security settings it may be troublesome to actually make these changes.

The file is here on a default install of XMetaL Author Enterprise 6.0 on Windows XP:
C:\Program Files\XMetaL 6.0\Author\DITA\XACs\shared\object\js\object_op.js

The code that does the unit conversion is this:

Code:

    // If there are units, convert it to pixels assuming 96dpi
    if (SVGwidth.indexOf("in") > 0) {
      SVGwidth  = parseInt(parseFloat(SVGwidth) * 96.0);
    } else if (SVGwidth.indexOf("cm") > 0) {
      SVGwidth  = parseInt(parseFloat(SVGwidth) * 96.0 / 2.54);
    }
    if (SVGheight.indexOf("in") > 0) {
      SVGheight = parseInt(parseFloat(SVGheight) * 96.0);
    } else if (SVGheight.indexOf("cm") > 0) {
      SVGheight = parseInt(parseFloat(SVGheight) * 96.0 / 2.54);
    }

Adding another 'else if' to each of those, as follows, should give you mm support:

Code:

    // If there are units, convert it to pixels assuming 96dpi
    if (SVGwidth.indexOf("in") > 0) {
      SVGwidth  = parseInt(parseFloat(SVGwidth) * 96.0);
    } else if (SVGwidth.indexOf("cm") > 0) {
      SVGwidth  = parseInt(parseFloat(SVGwidth) * 96.0 / 2.54);
    } else if (SVGwidth.indexOf("mm") > 0) {
      SVGwidth = parseInt(parseFloat(SVGwidth) * 96.0 / 25.4);
    }
    if (SVGheight.indexOf("in") > 0) {
      SVGheight = parseInt(parseFloat(SVGheight) * 96.0);
    } else if (SVGheight.indexOf("cm") > 0) {
      SVGheight = parseInt(parseFloat(SVGheight) * 96.0 / 2.54);
    } else if (SVGheight.indexOf("mm") > 0) {
      SVGheight = parseInt(parseFloat(SVGheight) * 96.0 / 25.4);
    }

If you don't feel comfortable modifying script I would not attempt this. Officially, making modifications to the product like this is not supported, so you will need to make that decision.

Best to back up that file before making the change so you can easily restore the original.

I'll make a recommendation that we try to extend this portion of the code to handle all the common units that might be set inside an SVG file (I guess we thought we had them all based on various sample SVG files we had seen at the time).

[dlemkuil]

This is great, Derek! Just the info I was looking for. We've added the code and it works. Hopefully this will be a soon-to-be-released patch.

You've been a big help and I appreciate your work on this issue. You've made my job a lot easier.

Regards,
Dave

[Derek Read]

XMetaL Author Enterprise 6.0.2.070 (6.0 SP1) supports these units: in, cm, mm, px, pt, pc

When no units are specified pixels are assumed.