I've been trying to get XPointer URIs working in an SVG file, but haven't had any luck so far. After trying something more complicated and failing, I simplified it down to just referencing an ID. However, this still fails.
The spec seems pretty clear about this implementation:
http://www.w3.org/TR/SVG/struct.html#URIReference
I found an example online of what should be a working XPointer reference within an svg document. Here is the Original. Here is the version I copied out:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="500" height="200" version="1.1"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink">
<defs>
<rect id="simpleRect" width="100px" height="75px"/>
</defs>
<use xlink:href="#simpleRect"
x="50" y="50" style="fill:red"/>
<use xlink:href="#xpointer(id('simpleRect'))"
x="250" y="50" style="fill:yellow"/>
</svg>
This should display two rectangles... one red and one yellow. I tried rendering with Firefox 3.6 and Inkscape 0.47. No success. Only the Red rectangle shows.
What am I missing?
Thanks for any help you can offer
There is currently (as of 10 March 2016, SVG 1.1 Second Edition) no support for rendering XPointers in browsers. W3Schools writes about this as follows:
XPointer Browser Support
There is no browser support for XPointer. But XPointer is used in other XML languages.
It's kind of frustrating, because all the official documentation does not bother to distinguish between browser-supported (Internet ready) features of SVG and the technically-supported, purely XML-like features of SVG.
From the linking section of the spec:
<URI-reference> = [ <absoluteURI> | <relativeURI> ] [ "#" <elementID> ] -or-
<URI-reference> = [ <absoluteURI> | <relativeURI> ] [ "#xpointer(id(" <elementID> "))" ]
So what is the benefit of using xpointer syntax? All svg implementions I've seen have supported the alternative (shorter) syntax shown above (#myId). The xpointer syntax seems to be less well supported.
Related
I've written some SVG:
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="100%" height="100%" version="1.1"
xmlns="http://www.w3.org/2000/svg">
<ellipse cx="150" cy="75" rx="100" ry="75" fill="rgb(200,240,120)" stroke="rgb(200,240,120)" stroke-width="3px" />
</svg>
It renders like this
I want to convert the fill color render effect to look like this
I have read the w3c document about SVG. I tried filter but It doesn't work like those images.
What you want to do is called a "hatch pattern". Do a web search for how to do that in SVG. Basically you need to define your hatch using the <pattern> element.
The following SO question may help you: Simple fill pattern in svg : diagonal hatching
Note that the unfinished SVG2 standard defines a new <hatch> element that will make creating hatch patterns a lot easier. However you cannot use this yet because no browser has implemented <hatch> yet.
I'm writing a web application which generates SVG images in the browser.
The SVG's I'm generating work fine in ever browser. However, when I download one of the SVG's and try to open it in Adobe Illsutrator, all the transformations are all over the place.
They are in fact so different that you have to zoom right out to see where the shapes are positioned.
This is the contents of the SVG, you can see it's pretty simple. Just a couple of nested SVG's and a few basic shapes:
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" width="592" height="592" xmlns:xlink="http://www.w3.org/1999/xlink">
<svg style="overflow:visible;" x="88.80000305175781" y="88.80000305175781" fill="#777777">
<svg style="overflow:visible;" height="100px" width="100px">
<rect width="100" height="100" style="stroke:#006600;" transform="scale(4.144 4.144)"></rect>
</svg>
</svg>
<svg style="overflow:visible;" width="592" height="592" x="176.60000000000016" y="177.60000000000014" fill="#000000">
<rect width="592" height="592" fill="rgba(0,0,0,0)" stroke="#bbbbbb" transform="scale(0.4 0.4)"></rect>
<svg style="overflow:visible;" x="-0.0000015258789005656581" y="-0.0000015258789005656581">
<svg style="overflow:visible;" height="48px" width="48px">
<ellipse id="SvgjsEllipse1010" rx="24" ry="24" cx="24" cy="24" style="stroke:#006600;fill:#00cc00;" transform="scale(4.933333333333334 4.933333333333334)"></ellipse>
</svg>
</svg>
</svg>
</svg>
I don't know the SVG spec inside out, but I'm doing anything particularly complex, so it all seems good to me. I can't see a reason why Illustrator would render it so differently to browsers.
Does anyone know why this is happening?
Edit
This is what it looks like in Illsutrator, as you can see the scaling and positioning is all off, the small square in the center is the 592 x 592 canvas area, so you can see who far I am zoomed out.
I suspect AI doesn't like/handle/expect nested <svg> elements. Try replacing them with groups. Those with x and y attributes may need to have a transform added to get it to look the same. Also if the overflow is important, you may need to tweak things further as that property is not valid for group elements.
I just learned that Modernizr uses two different classes for SVG support: no-svg and no-inlinesvg. I can't seem to understand the difference between the two.
According to caniuse.com, Safari 5 and below does not support inline SVG, but does support SVG. I tested this on some D3.js visualizations (them rendering SVG) and Safari 5 displays that correctly.
My first guess was that D3 produces inline SVG, but that does not seem to be the case. So I would love to hear an explanation of the difference between the two.
Inline SVG means using <svg> (and child) tags directly in your html document:
<!DOCTYPE html>
<html>
<body>
<svg width="300px" height="300px" xmlns="http://www.w3.org/2000/svg">
<text x="10" y="50" font-size="30">My SVG</text>
</svg>
</body>
</html>
SVG Support refers to the ability to understand and display SVG files using the <embed> or <object> tags.
Dear Stack Overflow,
I am trying to reference individual SVG graphics which reside in different SVG files
via the tag and ID numbers in a master HTML5 page.
I want to be able to put onclicks on the use tags in the HTML page in order to
make a multiple choice quiz (and then keep a score which I know how to do),
The graphics are going to be bulky. Therefore, these need to be in an external svg files.
Here however, I have used a simple rectangle to make my question easier to
follow
Here is my HTML
<html>
<head></head>
<body>
<svg>
<use xlink:href="LINK.svg#link" />
</svg>
</body>
</html>
and here is My SVG
<?xml version="1.0" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg">
<g id="link">
<rect x="0" y="0" width="50" height="50" style="fill:red"/>
</g>
</svg>
This works exactly the way I want it to in Firefox and Opera.
However, it does not work in Chrome or Safari. Not sure about Internet Explorer
Is there an alternative method that will allow me external access to the
SVG data, and scripting from the main HTML page (because I want can keep a score
over multiple SVG elements)
You could access your SVG by using an <object> tag. This link shows you how to script from html to SVG and vice versa.
I'm trying to create an SVG document that includes image tags referencing png files. This works if I include the absolute path of the png in every image tag but if I try putting an xml:base attribute in it doesn't seem to work in IE9. However it does seem to work Firefox and Chrome. Is there a bug in IE or is there something wrong with my syntax?
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:base="file:///C:/SVG/Devices/valves/">
<image width="40" height="56" x="10" y="10" xlink:href="motorised_valve[purple].gif"/>
</svg>
For complicated reasons I don't want to go into here, I can't put the SVG document into the same folder as the images.
Thanks for any help
Mog
Would it be acceptable in your case to embed your PNG images in your document using the data:// protocol? That would solve your problem, at the expense of potentially making the XML rather large.