1396294 - SVG icon is not rendered correctly in extension temporary installation/options views

Status: VERIFIED INVALID

(Core :: SVG, defect, P3)

Description

[User Dderss]

Attachment: colour-visited-urls.svg

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170824053622

Steps to reproduce:

Created an SVG icon with the use of the latest Inkscape vector graphics editor (saved, as advised in the documentation, in simple SVG format) for my web extension.


Actual results:

While the icon is displayed properly in general extensions list, it gets cut around the borders in the temporary installed extension view, and, much worse, gets totally skewed rendering in extensions' options view.


Expected results:

The icon should be displayer correctly in all three modes/views, not just in one.

Comment 1

[User Dderss]

Attachment: Proper SVG, saved as simple, via lated Inkscape.png

Comment 2

[User Dderss]

Attachment: Totally correct SVG rendering in general list of installed extensions.png

Comment 3

[User Dderss]

Attachment: Right side of SVG is cut in termporary extension installation view.png

Comment 4

[User Dderss]

Attachment: Lower part of SVG is shifted to the left in extension options view.png

Comment 5

[Daniel Holbert [:dholbert]]

Thanks for the bug report. Could you post the extension itself (or even a dummy version of the extension with just the image), for testing purposes?  (Or alternately, steps to create an extension with the image, so that folks looking at this bug can reproduce the rendering shown in your screenshots, for further investigation.)

Comment 6

[User Dderss]

Attachment: Extension.rar

The extension is not really ready, but here it is.

Comment 7

[Daniel Holbert [:dholbert]]

Thanks!

On my (linux) system I'm not seeing the "Lower part of SVG is shifted to the left" issue, but here are a few observations:

 (1) I'm not surprised that you're seeing it shifted left, since that <text> has |x="-0.44859466"|, which (for a high enough resolution) gets rounded up to a full pixel of being offset to the left.  So I think that some possible-1px-left-shifting there is expected.

 (2) I do see some right-edge text clipping at various zoom levels, like in your attachment 8903945 [details]. I can reproduce the clipping by just loading the SVG (attachment 8903942 [details]) directly -- i.e. in its own tab -- and zooming in and out with Ctrl +.  This kind of emulates what's happening in the addon UI, where the image is shown at various sizes.  On my system, the "D" in "VISITED" is clipped at the default zoomlevel, and if I zoom in 2x or 5x. I believe that's to be expected too, though, because:
  (a) You're not providing your own font, so you'll just get whatever font the system happens to pick. So you don't have any particularly good guarantees about how big the text will be.

  (b) Setting that aside: fonts are tricky, so a given font rendered at 2x size won't necessarily produce *exactly* 2x the width. It might be slightly wider, as it seems to be in this case.


So I think this bug is INVALID because you're asking SVG text to provide you more guarantees than it actually can provide.

I'm not an icon designer, so I don't claim to know best practices here -- but I'd bet if you want this to work reliably, you should consider doing the following:

EITHER:
 (1) don't use text -- instead, draw the text using shapes, which will scale nicely and won't invoke a font engine.
OR:
 (2) provide your own font (as a base64-encoded data URI, for example) inside of the SVG icon, so that you actually have good cross-platform guarantees (and you're not beholden to the renderer's font engine & its choice of font).  And include 1px or so of buffer around the edge, so that any rounding issues don't end up making your rightmost pixel of text get clipped.

Comment 8

[User Dderss]

Thanks, Daniel.

I have transmutated text object into vector ("Object to path" in Inkscape), and this has helped.

I am not a professional in SVG at all, and Inkscape does not tell you if it only saves text with a reference to some abstract font, I though it should include the vector for letters used, but it does not, and there is no warning.

Could you please update Mozilla's web extensions' tutorial for it to include a warning for newbies such as myself? Something like: "if your icon contains text, make sure you convert it to a vector object as otherwise consistent rendering is not guaranted".

Thank you in advance.

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to User Dderss from comment #8)
> I have transmutated text object into vector ("Object to path" in Inkscape),
> and this has helped.

Perfect, that sounds like exactly the right way to fix this.  I'm glad Inkscape makes this option available.

> Could you please update Mozilla's web extensions' tutorial for it to include
> a warning for newbies such as myself? Something like: "if your icon contains
> text, make sure you convert it to a vector object as otherwise consistent
> rendering is not guaranted".

I'm guessing you're talking about this doc:
 https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Your_first_WebExtension

I added a caveat after the mention of SVG for icons there:
  # Alternatively, you could supply an SVG file here, and it will be scaled correctly.
  # (Though: if you're using SVG and your icon includes text, you may want to use your
  # SVG editor's "convert to path" tool to flatten the text, so that it scales with a
  # consistent size/position.)

(The first line is the existing documentation, the other lines are what I added.)

I used the term "Convert to path" since that's what Inkscape's English documentation seems to call this feature. (See  https://inkscape.org/en/doc/tutorials/advanced/tutorial-advanced.en.html , "Converting to path" section).  That should be enough of a hint to steer people in the right direction.

Comment 10

[User Dderss]

Thanks, Daniel.

Did you look at YouTube's latest client JS engine update? It seems that the latest trend is to get rid of as much raster images as possible, and replace them with SVG (be it inline vector code or links to SVG files). 

Could you please consider with your colleagues to make the SVG instructions as the primary recommended practice in the tutorial? This also would remove the necessity to define sizes like "48", "96", and so on in the Manifest file.

Additionally, Firefox/Thunderbird/et cetera as whole should also exclude any and all raster graphics everywhere, making it ever sharp and infinitely scalable. Even cheap Android phones by now have decent 2D vector acceleration capabilities, so such transition could be done on common multi-platform resource storage level.

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to User Dderss from comment #10)
> Could you please consider with your colleagues to make the SVG instructions
> as the primary recommended practice in the tutorial? This also would remove
> the necessity to define sizes like "48", "96", and so on in the Manifest
> file.

I'll pass that along if I run into folks on our WebExtensions team. (I don't immediately know who the right person would be to direct that feedback to.)

I imagine the situation might be slightly complex, e.g. perhaps they're trying to make that guide approachable to legacy addon authors who are rewriting their addons as WebExtensions, and who already have PNG assets.  And maybe we don't want to scare them away by pushing SVG on them. *shrug*, I dunno.

> Additionally, Firefox/Thunderbird/et cetera as whole should also exclude any
> and all raster graphics everywhere, making it ever sharp and infinitely
> scalable.

On desktop Firefox at least, we're already replacing the icons in Firefox UI with SVG versions, as part of the "photon" retheming, which ships in Firefox 57 -- see e.g. bug 1347543 (and bug 1355455 which I think switches them on).  You can see the new UI in current Nightly versions, if you like.