Created attachment 268460 [details] test-case When a 'rect' (rectangle) is drawn in SVG I observe the stroke being thicker than specified 'stroke-width' and the equivalent specified value for a 'line'. This is only an issue in SVG and specifying shape-rendering="crispEdges" does not help. I have not found any work around and this impacts quality of rendered images. I have not tested for other stroke scenarios. SVG Sample ---------- <!-- Line thickness as expected --> <svg id="svg1" style="width: 200px; height: 200px; background: white" shape-rendering="crispEdges"> <line x1="0" x2="200" y1="20" y2="20" stroke="#000000" style="stroke-width: 1px;"></line> <line x1="0" x2="200" y1="40" y2="40" stroke="#000000" style="stroke-width: 2px;"></line> </svg> <!-- Line thickness does not correspond to simple lines --> <svg id="svg2" style="width: 200px; height: 200px; background: white" shape-rendering="crispEdges"> <rect x="80" y="80" width="40" height="40" stroke="#000000" fill="none" style="stroke-width: 1px;"></rect> <rect x="70" y="70" width="60" height="60" stroke="#000000" fill="none" style="stroke-width: 2px;"></rect> </svg> Browsers Tested In ------------------ I observe this behaviour: - Webkit nightly 2016-07-01 (MacOS X 10.11) - Safari 9.0.2 (MacOS X 10.11) - Safari and other webkit based browsers on iOS 9.2 Behaves as expected: - Opera 34 (MacOS X 10.11) - Google Chrome 43 (MacOS X 10.11)
Created attachment 268645 [details] Screenshot showing what I am seeing
Created attachment 268647 [details] second test case
I looked at Chromium build 100008 (https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Mac/100008/), from September 2011, and the issue does not present itself there. I was looking to establish at what point the behaviour diverged in Google Chrome and Safari, but this offered no clue.
Created attachment 268690 [details] third test case
I can't reproduce this bug in the shipped Safari on Mac OS X El Capitan. The display is identical with Chrome and FireFox on the same machine. I tried the webkit nightly build and the display is as expected also.
I certainly see the issue with a 13" MacBook Air (MacBookAir6,2), without extra display and with the iPad Air 1. I have since tested with other computers: - 15" MacBook Pro , late 2008 (MacBookPro5,1), MacOS 10.9.3: looks fine - 27" iMac, mid 2011 (iMac 12,2), MacOS 10.11.2: thick line issue - Mac mini, early 2009 (Macmini3,1): thick line issue For the MacOS test, what machine are you using? Are there any screen metrics available via the DOM, that I could look at to see if there are differences in the indicated screen DPI or something similar? I want to avoid delving into the code if I don't need to, for initial analysis. Note, I wasn't able to test Webkit nightly with MacOS X 10.9, so I can't tell whether the issue is due to regression or something else.
Just noticed something on my 13" MacBook Air, when I tested your test case (Safari & Webkit nightly): a: Looks ok: - New tab - Paste in and display test case b: Looks problematic: - New tab - Open test case page - Display web inspector c: Looks problematic: - New tab - Visit any website, www.webkit.org - Display web inspector - Open test case page Note in cases b & c closing the inspector and reloading the page in the same pane doesn't correct the line thickness. Further, depending on whether I open your test case from the URL or file, the behaviour is different. From the web site it looks fine (as describe in cases b & c), but is always problematic from file.
Yes, you are right. It seems to be hardware specific. I can't repro this bug on MacBookPro11,3. But I can repro it on MacPro6.1 only on WK2.
Created attachment 268699 [details] Screenshot-MacBookPro11,3
Created attachment 268700 [details] Screenshot-MacPro6,1
Safari, Chrome, and Firefox all agree on rendering for this test case. I don't believe there is any remaining compatibility issue.