Blockly workspace background shows random image? - google-chrome

I'm facing a weird bug which cause background of Blockly shows random image
The correct background should be like this:
But it shows random image (mostly favicon?) instead
It's really too weird to describe in words, please take a look at this screen record
I extract svg from Blockly (which I used in the video) that can reproduce the bug
<svg xmlns="http://www.w3.org/2000/svg" xmlns:html="http://www.w3.org/1999/xhtml" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" class="blocklySvg" width="1209px" height="270px" style="display: block;">
<defs>
<pattern id="blocklyGridPattern5105292194395497" patternUnits="userSpaceOnUse" width="25" height="25" x="1202" y="219">
<line stroke="#ccc" stroke-width="1" x1="11" y1="12.5" x2="14" y2="12.5"></line>
<line stroke="#ccc" stroke-width="1" x1="12.5" y1="11" x2="12.5" y2="14"></line>
</pattern>
</defs>
<g class="blocklyWorkspace">
<rect height="100%" width="100%" class="blocklyMainBackground" style="fill: url(#blocklyGridPattern5105292194395497);"></rect>
</g>
</svg>
Is this a bug related to Chrome? or I misconfigured something?
Additional info about my environment
Chrome 56 (seems only happens in Chrome)
MacOS 10.12.4

After doing some investigation, I think this is a bug of Chrome.
I already reported it to Chromium, and they can finally reproduce this bug.
I answer my question just for record, in case someone have same issue.

Related

SVG images not rendering in Safari

<svg id="button-svg" xmlns="http://www.w3.org/2000/svg" x="0px" y="0px" viewBox="0 0 40 40" xml:space="preserve">
<defs>
<pattern id="pattern1" height="100%" width="100%">
<filter id="shadow">
<feDropShadow dx="0" dy="0" stdDeviation="2.2" />
</filter>
<rect height="100%" width="100%" fill=${backgroundColor}></rect>
<image id="image" xlink:href=${backgroundImage}></image>
</pattern>
</defs>
<circle id="circle" cx="20" cy="20" r="20" filter="url(#shadow)" fill="url(#pattern1)"/>
</svg>
I have tried multiple solutions from stackoverflow but none seem to work. Can anybody please help me on this?
Note: both filter and the fill color are showing. It’s only the image that’s missing.
Demo: https://codesandbox.io/s/svg-safari-image-t9ng3?file=/src/index.js
Edit: Thank's to Robert Longson's answer I found out that you need to set the height and width explicitly in the image tags 'height/width' attribute for the image to show in Safari. Now I have another problem if the height/width is supposed to be 'auto', removing the attribute from the image tag works in Chrome but the image again disappears in Safari. Is there any fix for this?
Safari needs the image to have height and width values.
Using the image's native width and height i.e. a default value of auto is a change in the new SVG 2 specification. Firefox and Chrome have implemented this and I imagine Safari will too at some point.

SVG path (ellipse) fill with image does not work (except Chrome on MacOS)

Created a simple SVG with an ellipse. I want that ellipse to get filled with an external image. It shows OK on Chrome on MacOS but on no other agent. What is wrong ?
Searched a lot of other questions here but none is helpful, it seems.
Codepen
<svg version="1.2" baseProfile="tiny" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
x="100px" y="100px" viewBox="0 0 177.5 175" xml:space="preserve">
<defs>
<pattern id="image" x="0" y="0" patternUnits="userSpaceOnUse" height="200" width="200">
<image x="100" y="1000" xlink:href="http://i.imgur.com/7Nlcay7.jpg"></image>
</pattern>
</defs>
<ellipse id="FillThisWithColorOrPattern" style="fill:url(#image)" stroke="#333333" stroke-miterlimit="10" cx="90" cy="87" rx="87.5" ry="82"/>
<circle id="Inner_1_" fill="#FF0000" cx="90" cy="87" r="35"/>
<path id="TextLine1_Path" fill=None
d="M90,137.5c-27.8,0-50.5-22.7-50.5-50.5S62.2,36.5,90,36.5s50.5,22.7,50.5,50.5S117.8,137.5,90,137.5z M90,37.5
c-27.3,0-49.5,22.2-49.5,49.5s22.2,49.5,49.5,49.5c27.3,0,49.5-22.2,49.5-49.5S117.3,37.5,90,37.5z"/>
<text>
    <textPath xlink:href="#TextLine1_Path">
      The quick brown fox jumps over the lazy dog.
    </textPath>
  </text>
</svg>
It seems that you have to specify a width and a height to your image for other browsers. I tried with Firefox 58 and Safari 11 on MacOS and the pattern is there.
<image x="0" y="0" xlink:href="http://i.imgur.com/7Nlcay7.jpg" width="200" height="200"/>
Here's your example updated: https://codepen.io/anon/pen/RJeMda
Also, note that xlink:href is deprecated since SVG 2. You should now use href. The MDN doc adds:
For browsers implementing href, if both href and xlink:href are set, xlink:href will be ignored and only href will be used.

Making RSVG properly display text with a fractional size

I'm using librsvg 2.39.0 to render the following SVG file to PNG. Inkscape and Firefox render it without any issues:
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" width="400" height="200" viewBox="0 0 20 10" version="1.1">
<rect width="100%" height="100%" fill="#ffffff" />
<text style="font-family: Helvetica;" stroke="none" x="7" y="5" font-size="1.6" fill="black">
This is some text
</text>
</svg>
However, it looks like, with librsvg, the text characters get aligned to the user coordinate grid, and the kerning is completely broken:
The issue can be replicated in the console by installing the librsvg2-tools package and running rsvg-convert < input.svg > output.png.
Is there something wrong with the file? The W3C validator shows it as valid. How do I teach librsvg to accept a fractional font-size in user coordinates?
This works fine now with rsvg-convert 2.40.20

How to render svg elements with crisp edges while still keeping anti-aliasing?

Is there a way to render svg elements with crisp edges while still keeping anti-aliasing?
I'm creating a browser-based tool that works in modern browsers.
Playing around with the shape-rendering attribute doesn't give me the results I'm looking for.
I want my elements to have nice anti-aliasing so that the paths look smooth like below with shape-rendering: auto:
But I also want elements that don't require anti-aliasing, like the start box to look sharp and crisp, such as when rendered with shape-rendering: crispEdges:
Is this possible? Am I looking to have my cake and eat it too?
Perhaps you set shape-rendering property for root svg element.
You should set shape-rendering property for each shape elements, like this.
<?xml version="1.0" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<rect x="10" y="10" width="150" height="20" shape-rendering="crispEdges"
fill="none" stroke="black"/>
<path d="M80,30l100,100" shape-rendering="optimizeQuality"
stroke="black" stroke-width="5"/>
</svg>
If you want your boxes to appear sharp without any blurring due to antialiasing, and without using crispEdges mode, make sure the line edges are on pixel boundaries. So, for example, if your lines are an odd number of pixels wide, give them coordinates that are at 0.5 of a pixel.
<rect x="10.5" y="10.5" width="150" height="20"
stroke-width="1px" fill="none" stroke="black"/>
And on the boundary if the stroke width is even.
<rect x="10" y="10" width="150" height="20"
stroke-width="2px" fill="none" stroke="black"/>
Of course, this only really works if your SVG is being rendered at 1:1. That is, it's not being rescaled by the browser. And only for lines that are horizontal and vertical.
[I'm posting this as an answer rather than a comment, because I want to post a picture. Otherwise, this is a comment on the useful post by #defghi1977 . +1 to him, by the way.]
<?xml version="1.0" standalone="no"?>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<rect x="10" y="10" width="150" height="20" shape-rendering="crispEdges"
fill="none" stroke="black" />
<rect x="10" y="50" width="150" height="20" shape-rendering="auto"
fill="none" stroke="black" />
<path d="M40,30l100,100" shape-rendering="crispEdges"
stroke="black" stroke-width="5" />
<path d="M80,30l100,100" shape-rendering="auto"
stroke="black" stroke-width="5" />
</svg>
Produced
This was rendered by Firefox 38.0.5 .
In Internet Explorer 11, both shape-rendering setting produces the same result with anti-aliasing and not crisp.

Why do markers, patterns, and unicode characters display incorrectly in a svg data uri in google chrome?

I am using google chrome version 24.0.1312.57 on Mac OS X 10.6.8.
In Safari 5.1.7 the svg image looks like this:
In Chrome it looks like this:
Notice the markers are gone from the paths and the path that has a pattern now has a fill of black and the unicode character has an A behind it. This only happens if the image is a data uri in the address bar in google chrome. If I open the svg image up as a file in chrome it displays correctly.
I've tried taking the line endings away and putting it in base64, but it doesn't seem to fix anything.
Is this a bug with chrome or am I missing something?
Here's the source svg:
<svg width="200" height="200" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" id="svg_elem">
<title id="doctitle">URI Test</title>
<defs id="thedefs">
<pattern id="ptrn" overflow="visible" patternUnits="userSpaceOnUse"
x="0" y="0" width="10" height="10"
viewBox="0 0 10 10" >
<line fill="none" stroke="#000000" stroke-width="0.5" x1="-5" y1="-5" x2="15" y2="15"/>
</pattern>
<marker id="mtriangle" viewBox="0 0 10 10" refX="0" refY="5" markerUnits="strokeWidth" markerWidth="4" markerHeight="3" orient="auto">
<path d="M 0 0 L 10 5 L 0 10 z" fill="#FFF" stroke="#000" stroke-width="1"/>
</marker>
<marker id="mcircle" viewBox="-2 -2 12 12" refX="5" refY="5" markerUnits="strokeWidth" markerWidth="4" markerHeight="3" orient="auto">
<circle cx="5" cy="5" r="5" fill="#FFF" stroke="#000" stroke-width="1"/>
</marker>
</defs>
<g>
<path
fill="#F00"
stroke="#000000"
stroke-width="3"
marker-start="url(#mtriangle)"
marker-mid="url(#mcircle)"
d="M10,10l0,60l60,0z"/>
<path
fill="url(#ptrn)"
stroke="#000"
stroke-width="3"
marker-start="url(#mtriangle)"
marker-mid="url(#mcircle)"
d="M110,110l0,70l70,0z"/>
<text
fill="#000"
x='100'
y='100'
font-size="14pt"
font-family="serif"
text-anchor="middle"
space="preserve">N 34° 45' 30" E 300 ft</text>
</g>
</svg>
Here's the data uri.
data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iODUwIiBoZWlnaHQ9IjEwNTAiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIGlkPSJzdmdfZWxlbSI+PHRpdGxlIGlkPSJkb2N0aXRsZSI+VVJJIFRlc3Q8L3RpdGxlPjxkZWZzIGlkPSJ0aGVkZWZzIj4gICAgPHBhdHRlcm4gaWQ9InB0cm4iIG92ZXJmbG93PSJ2aXNpYmxlIiBwYXR0ZXJuVW5pdHM9InVzZXJTcGFjZU9uVXNlIiB4PSIwIiB5PSIwIiB3aWR0aD0iMTAiIGhlaWdodD0iMTAiIHZpZXdCb3g9IjAgMCAxMCAxMCI+ICAgICAgICA8bGluZSBmaWxsPSJub25lIiBzdHJva2U9IiMwMDAwMDAiIHN0cm9rZS13aWR0aD0iMC41IiB4MT0iLTUiIHkxPSItNSIgeDI9IjE1IiB5Mj0iMTUiPjwvbGluZT4gICAgPC9wYXR0ZXJuPiAgICA8bWFya2VyIGlkPSJtdHJpYW5nbGUiIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iMCIgcmVmWT0iNSIgbWFya2VyVW5pdHM9InN0cm9rZVdpZHRoIiBtYXJrZXJXaWR0aD0iNCIgbWFya2VySGVpZ2h0PSIzIiBvcmllbnQ9ImF1dG8iPiAgICAgIDxwYXRoIGQ9Ik0gMCAwIEwgMTAgNSBMIDAgMTAgeiIgZmlsbD0iI0ZGRiIgc3Ryb2tlPSIjMDAwIiBzdHJva2Utd2lkdGg9IjEiPjwvcGF0aD4gICAgPC9tYXJrZXI+ICAgIDxtYXJrZXIgaWQ9Im1jaXJjbGUiIHZpZXdCb3g9Ii0yIC0yIDEyIDEyIiByZWZYPSI1IiByZWZZPSI1IiBtYXJrZXJVbml0cz0ic3Ryb2tlV2lkdGgiIG1hcmtlcldpZHRoPSI0IiBtYXJrZXJIZWlnaHQ9IjMiIG9yaWVudD0iYXV0byI+ICAgICAgPGNpcmNsZSBjeD0iNSIgY3k9IjUiIHI9IjUiIGZpbGw9IiNGRkYiIHN0cm9rZT0iIzAwMCIgc3Ryb2tlLXdpZHRoPSIxIj48L2NpcmNsZT4gICAgPC9tYXJrZXI+ICAgIDwvZGVmcz48Zz4gPHBhdGggZmlsbD0iI0YwMCIgc3Ryb2tlPSIjMDAwMDAwIiBzdHJva2Utd2lkdGg9IjMiIG1hcmtlci1zdGFydD0idXJsKCNtdHJpYW5nbGUpIiBtYXJrZXItbWlkPSJ1cmwoI21jaXJjbGUpIiBkPSJNMTAsMTBsMCw2MGw2MCwweiI+PC9wYXRoPiAgICAgIDxwYXRoIGZpbGw9InVybCgjcHRybikiIHN0cm9rZT0iIzAwMCIgc3Ryb2tlLXdpZHRoPSIzIiBtYXJrZXItc3RhcnQ9InVybCgjbXRyaWFuZ2xlKSIgbWFya2VyLW1pZD0idXJsKCNtY2lyY2xlKSIgZD0iTTExMCwxMTBsMCw3MGw3MCwweiI+PC9wYXRoPiAgICAgICAgICAgICAgPHRleHQgZmlsbD0iIzAwMCIgeD0iMTAwIiB5PSIxMDAiIGZvbnQtc2l6ZT0iMTRwdCIgZm9udC1mYW1pbHk9InNlcmlmIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzcGFjZT0icHJlc2VydmUiPk4gMzTCsCA0NScgMzAiIEUgMzAwIGZ0PC90ZXh0PjwvZz48L3N2Zz4JCQk=
Not sure about markers and patterns, but as for the character set, Chrome must be using a different default encoding for data:URIs. If you add charset=UTF-8; in the beginning, e.g.:
data:image/svg+xml;charset=UTF-8;base64,PHN2ZyB3aWR0aD0iODUwIiBoZWlnaHQ9IjEwNTAiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIGlkPSJzdmdfZWxlbSI+PHRpdGxlIGlkPSJkb2N0aXRsZSI+VVJJIFRlc3Q8L3RpdGxlPjxkZWZzIGlkPSJ0aGVkZWZzIj4gICAgPHBhdHRlcm4gaWQ9InB0cm4iIG92ZXJmbG93PSJ2aXNpYmxlIiBwYXR0ZXJuVW5pdHM9InVzZXJTcGFjZU9uVXNlIiB4PSIwIiB5PSIwIiB3aWR0aD0iMTAiIGhlaWdodD0iMTAiIHZpZXdCb3g9IjAgMCAxMCAxMCI+ICAgICAgICA8bGluZSBmaWxsPSJub25lIiBzdHJva2U9IiMwMDAwMDAiIHN0cm9rZS13aWR0aD0iMC41IiB4MT0iLTUiIHkxPSItNSIgeDI9IjE1IiB5Mj0iMTUiPjwvbGluZT4gICAgPC9wYXR0ZXJuPiAgICA8bWFya2VyIGlkPSJtdHJpYW5nbGUiIHZpZXdCb3g9IjAgMCAxMCAxMCIgcmVmWD0iMCIgcmVmWT0iNSIgbWFya2VyVW5pdHM9InN0cm9rZVdpZHRoIiBtYXJrZXJXaWR0aD0iNCIgbWFya2VySGVpZ2h0PSIzIiBvcmllbnQ9ImF1dG8iPiAgICAgIDxwYXRoIGQ9Ik0gMCAwIEwgMTAgNSBMIDAgMTAgeiIgZmlsbD0iI0ZGRiIgc3Ryb2tlPSIjMDAwIiBzdHJva2Utd2lkdGg9IjEiPjwvcGF0aD4gICAgPC9tYXJrZXI+ICAgIDxtYXJrZXIgaWQ9Im1jaXJjbGUiIHZpZXdCb3g9Ii0yIC0yIDEyIDEyIiByZWZYPSI1IiByZWZZPSI1IiBtYXJrZXJVbml0cz0ic3Ryb2tlV2lkdGgiIG1hcmtlcldpZHRoPSI0IiBtYXJrZXJIZWlnaHQ9IjMiIG9yaWVudD0iYXV0byI+ICAgICAgPGNpcmNsZSBjeD0iNSIgY3k9IjUiIHI9IjUiIGZpbGw9IiNGRkYiIHN0cm9rZT0iIzAwMCIgc3Ryb2tlLXdpZHRoPSIxIj48L2NpcmNsZT4gICAgPC9tYXJrZXI+ICAgIDwvZGVmcz48Zz4gPHBhdGggZmlsbD0iI0YwMCIgc3Ryb2tlPSIjMDAwMDAwIiBzdHJva2Utd2lkdGg9IjMiIG1hcmtlci1zdGFydD0idXJsKCNtdHJpYW5nbGUpIiBtYXJrZXItbWlkPSJ1cmwoI21jaXJjbGUpIiBkPSJNMTAsMTBsMCw2MGw2MCwweiI+PC9wYXRoPiAgICAgIDxwYXRoIGZpbGw9InVybCgjcHRybikiIHN0cm9rZT0iIzAwMCIgc3Ryb2tlLXdpZHRoPSIzIiBtYXJrZXItc3RhcnQ9InVybCgjbXRyaWFuZ2xlKSIgbWFya2VyLW1pZD0idXJsKCNtY2lyY2xlKSIgZD0iTTExMCwxMTBsMCw3MGw3MCwweiI+PC9wYXRoPiAgICAgICAgICAgICAgPHRleHQgZmlsbD0iIzAwMCIgeD0iMTAwIiB5PSIxMDAiIGZvbnQtc2l6ZT0iMTRwdCIgZm9udC1mYW1pbHk9InNlcmlmIiB0ZXh0LWFuY2hvcj0ibWlkZGxlIiBzcGFjZT0icHJlc2VydmUiPk4gMzTCsCA0NScgMzAiIEUgMzAwIGZ0PC90ZXh0PjwvZz48L3N2Zz4JCQk=
...it should work properly!
Here's a fiddle.
EDIT Upon further inspection (re: markers and patterns), it seems like this is a bug in Chrome. It looks like Chrome incorrectly interprets (completely ignores?) url(#hash) attribute values in SVG data:URIs when embedded as <object> (and possibly in other cases?).
Here's another fiddle with extensive testing of this issue.
Everything works correctly for me in Safari 6.0.2, Firefox 18.0.2 (Mac), Firefox 10.0.1 (Win), Opera 12.12 (Mac), and IE 9. <object> (as well as <embed> and <iframe>) embeds are not displaying correctly in Chrome 24.0.1312.57 (Mac/Win) or 26.0.1405.0 canary (Mac), whereas <img> embeds are working fine. Pasting either the URI-encoded or base64-encoded data:URIs into the address bar is also not working.