With Chrome as my target browser, I'm adding a hand-edited SVG image to a webpage. The SVG image doesn't render, and Chrome shows a "broken image" icon in its place.
I suspect that the problem is that my hand-edited SVG has a typo somewhere in it, but without any further information, I'm not sure how to look for the mistake. Some kind of error message would be extremely useful. How do I see the error that prevented Chrome from rendering the SVG?
Have you tried the https://validator.nu/ validator?
Use "File Upload" or "Text Field" and select the SVG preset:
Add name space to your svg tag. Like mentioned below. That should make it work.
<svg xmlns="http://www.w3.org/2000/svg" version="1.1">
</svg>
Related
I worked on this project a couple of months ago and it worked fine. I open it up today and the SVG images are not showing on chrome. It does show in other browsers though. This is how I’m using them.
<svg>
<use xlink:href=“img/sprite.svg#icon-user”></use>
</svg>
You state it's visible in one browser but not another, so that indicates that the image is where it should be. Is there any possibility of any CSS affecting "icon-user"?
Which browser works and which doesn't? Having more detail may help lead to an answer for you.
Your code looks fine. Although you could shorten <use> with self closing tag:
<svg>
<use xlink:href=“img/sprite.svg#icon-user”/>
</svg>
Could it be that your image was moved/deleted/renamed and other browsers are just caching it?
I had a similar issue, and it was caused by symbol id duplicated in sprite.svg
It was reproducible only when chrome loading svg file from disk cache.
More details in related PR
Make sure you don't have any duplicate ids, even if it's not an icon-user.
I'm using SVGZ images on HTML pages for their resizability. These SVGZ images contain PNGs that have been enlarged in specific ways that I want to preserve, pixelation and all. Firefox is displaying this correctly (the way I designed it in Inkscape):
while Chrome is "helpfully" autosmoothing everything:
I'm teaching a course, and I'm trying to show how image data is being created over successive passes. I want the pixelation, because that's what the data is. In fact, the PNGs inside the SVGZ contain the property style="image-rendering:optimizeSpeed". I was hoping that Chrome would recognize that and respect it.
(Please note that I've already tried the CSS image-rendering: pixelated; trick. I'm sure that would work perfectly well if I were showing PNGs directly, but that's not what I'm doing.)
Works for me in Chrome:
<svg width="100" height="100">
<image xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAIAAAACCAYAAABytg0kAAAAFElEQVQIHWP4z8DwHwyBNJDN8B8AQNEG+t5Ik2kAAAAASUVORK5CYII=" width="100px" height="100px"/>
</svg>
<svg width="100" height="100">
<image xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAIAAAACCAYAAABytg0kAAAAFElEQVQIHWP4z8DwHwyBNJDN8B8AQNEG+t5Ik2kAAAAASUVORK5CYII=" width="100px" height="100px" style="image-rendering: pixelated"/>
</svg>
I found an answer that builds on what Paul said above.
It looks like the way to do this in Chrome is to make sure that the PNG inside the SVG/SVGZ has the property style="image-rendering: pixelated", which makes sense. However,
This doesn't work with Firefox.
This isn't an option within Inkscape, so if you want it you have to edit the SVG code manually.
Both Firefox and Inkscape seem to prefer style="image-rendering: optimizeSpeed". So I ended up adding both to my SVGZ file: style="image-rendering:optimizeSpeed;image-rendering:pixelated". This seems to make both browsers happy, though again it means modifying the SVG code of the image file manually, since Inkscape doesn't let you do it directly.
I'm going to add an Inkscape tag if I can, since this seems to involve that program as much as anything.
Firefox won't display the SVG book covers properly ...
http://new.images.hindawi.org/kalimat/covers/svg/270x360/c/24972860.svg
Compare the link above in Firefox and Chrome.
It used to be displayed just fine in Firefox, but I think something went wrong with the latest update.
If any one know a solution to this issue it would be great.
Thanks.
If you check your browser inspector, than you will see an error:
There is an SVG reference chain which is too long in this
document, which will prevent the document rendering correctly.
Inside your SVG image there are many of them, looking like:
<path clip-path="url(#SVGID_68_)" fill="#FFFFFF" d="..." />
Either create less accurate SVG (less details), or create it some other way.
Since it is rendered well in webkit browsers, than maybe you can use wkhtmltoimage to convert it server side to PNG or JPG.
I'm having a SVG file that's around 6300 lines long. Opening this file as .svg in Chrome works just fine. But as soon as I use it inline in an HTML file via the <object> tag only half the elements are drawn.
With Chrome's "analyze element" option I see, that the source for the embedded SVG is cut off.
I also tried Firefox, but here the SVG is as empty as before, with the only difference, that the missing elements are drawn underneath in strange positions.
If I open the SVG as external data via <object data=""> it works fine, but that is not a viable option, since my scripts are not properly working that way.
Because the SVG contains confidential data I can't link it here. I hope someone can help me.
Are you sure there is not a parsing problem with the file that is only happening when it is inlined? SVG renderers will generally stop rendering when they encounter the problem.
I would start by trying to locate the element it stops at. Then look for any oddities.
I have just started using inline SVG to display images on a resource heavy website. However, I also have a fallback using switch and foreignobject tags so that older browsers should just display a png image in its place.
Here is the bare bones - there are more details at inline svg in html - how to degrade gracefully?
<svg xmlns:xlink="http://www.w3.org/1999/xlink" xml:space='preserve'
width="100" height="100">
<switch>
<g>
<!-- the svg goes here -->
</g>
<foreignObject width="100" height="100">
<img src="/some_image.png"/>
</foreignObject>
</switch>
</svg>
I thought that this would lighten the load on the server - e.g. for a page with 4 images, the browser gets everything in one hit, rather than making 5 trips to the server, 1 for the page and 1 for each img tag.
However, now that I have deployed this solution, I have discovered (by examining the server logs) that browsers are actually processing the img requests inside the foreignobject tag, regardless of whether they can handle SVG.
In other words, it's increasing the load on the server since the page is much bigger (full of SVG) and the images are downloaded anyway, even though they are never displayed.
This seems crazy - I thought the idea of a switch was that the browser should process the first tag it understands (in my example, the g tag) and ignore the rest (the foreignobject in my example).
I have tested this in Firefox 17.0.1, Chrome 23.0.1271.95, Safari 5.1.7 and Opera 12.10 and they all do it.
Is there any way I can persuade the browsers that they really really don't need to download the images?
Thanks
Chris
You can still make reference to the content of a <switch> child that isn't directly displayed by using it in a <use> <filter> or <clipPath>. It's only direct rendering of switch children that is suppressed.
The only way to stop downloading would be not to set the src attribute on the image unless you need it. You could check for SVG support using javascript e.g.
document.implementation.hasFeature("http://www.w3.org/TR/SVG11/feature#Shape", "1.0")
and then set the src attributes if that returns true.