material symbols svg npm package

[ldsenow]

Is possible to also publish a npm package of symbols svg? We would like to use svg over font. This will be very convenient to have a svg npm package.

[tphinney]

Google is not currently maintaining any NPM package, whether for fonts or SVGs. Anyone else is welcome to do so, but… even if somebody wanted to, they would have to define which specific styles/instances they were going to cover.

One of the reasons for using the fonts is that everything can be handled with only three files. But besides over 2000 glyphs per font, with the variable font axes, there are 7 standard weights, at least 4 useful grades, filled and unfilled, and 4 standard sizes. That makes for 7x4x2x4 = 224 variants for each glyph, times >2000 glyphs times three fonts is… over a million SVG files.

You could reduce that an awful lot and still have an unwieldy number of files.

So, fonts are a good way to package all that variability compared to SVG files. Because three is a whole lot fewer files than a million-plus. That said, if you want some specific few styles, it would be more plausible.

[oliviertassinari]

@tphinney I'm not sure that I follow the reasoning on why SVGs aren't available. From what I understand, we could:

• /7: replace the 7 weights with a single SVG path + the use of the stroke-width. A prior art: https://feathericons.com/.
• /4: as far as I understand the grades: they are a change of the stroke width, but it's more granular. So assuming that the previous item works, it can be used to implement this.
• /4: the standard sizes. the optical size seems to be about changing the stroke width too, could it be parametrized?

So from what I understand, we need ~4,000 SVG files (2,000 x 2 for the filled value). Currently, we have 10,000 SVG files with the classic Material Icons (2,000 x 5 variants).

The context I'm coming from: mui/material-ui#32846, and being the author of https://mui.com/material-ui/material-icons/.

[tphinney]

Well, you could do something vaguely similar to the icon variants that way. But they are not created by stroked paths, and the results of stroked paths would be quite different than the existing icons.

I’m not even sure you could recreate the Regular style that way. Consider that the most basic shape throughout the icons involves rounded corners on the outside and sharp corners on the inside.

This same thing just came up in discussion with one of the Google folks, and I learned that while I was thinking 224 variants for each glyph would be good, they were only using 3 grades instead of the 4 I was assuming, so they “only” generated 168 variants… for each… single… icon.

[o-alexandrov]

@tphinney for the benefit of a better result in communities' projects, it'd be great to know whether you have any factual findings of the differences between the specified SVGs and the icon font. Reading from you the vaguely similar, could do, not sure are all non-definitive arguments for the Font Detective that, imho, resulted in a closure of a reasonable GitHub Issue.

https://mui.com/material-ui/material-icons

[tphinney]

I didn’t want to write a super lengthy essay, but since you won’t take no for an answer, here are the details.

NO, what you are suggesting WILL NOT WORK. You cannot exactly recreate the weight variation of the variable font by stroking SVG paths. It’s literally impossible. Yes, you can create something vaguely similar. It won’t be at all the same. We did not do the weight variation by stroking paths in the first place. Stroking paths won’t yield the same effects, any more than the faux bold and faux italic operations one can get from Mac and Windows OSes will yield the same results as real designed bold or italic.

SVG strokes add weight equally on on both sides of a path, right? And a scheme that treats things differently depending on where it is in the weight spectrum, and even treats different contours in the same icon differently.

If we could have gotten the various weights and masters by stroking paths, we either wouldn’t have bothered making a variable font, or our process for making that font would have been vastly easier. We didn’t do it because it couldn’t produce the same results.

In the case of the vector outlines in the font, as you go from the Regular to the lightest weight, the weight is coming off ONLY the inside of paths for outer contours. But if there are say also INTERIOR elements, they can get different treatment, and that might vary depending on the exact size and even shape of the interior element.

Contrariwise, as you go from Regular to Bold, the weight for outer shapes normally gets added to both inside and outside, but not equally (more to the inside).

Worse, SOME icons don’t get as bold at their boldest—or more often, perhaps an outer frame element does (to create a general appearance of boldness) but the inner part does not. And how bold the parts get that do not get the full bold treatment? That varies depending on what there was space to do, and also sometimes to be consistent with OTHER similar icons. For example, the various delete-related icons, the outer trash-can part goes from regular (80 font units) to full bold weight (126 font units). But the inner arrow in restore_from_trash only gains half as much extra weight when it goes bold.

On the other hand, the weight variation for the opsz (size) axis is different. The 20 px and 24 px masters are literally specifically designed to fit the grid at that size. The 48 px master is just a bit lighter than the 24 px. But it is designed such that the outer bounds of the inked area of the icon remain the same. Only… how one actually implements this in the glyph depends on the number of shapes involved, AND how exactly they are arranged. What does it mean to reduce stroke thickness slightly and keep the same outer bounds when you have: (A) a single box shape; (B) two vertically stacked rectangle-boxes; (C) three horizontally-stacked rectangle-boxes? Each one needs a different treatment.

And actually, the same problems apply to weight in general, when one does not want crazy differences in the outer bounds of the glyph to occur.

So, what we do in the font is complicated, and varies depending on particular cases.

Also, one kind of cool thing the variable font has is that the Fill axis can be used for animating the fill transition. It is directional, not just a dissolve from one static state to another. We have cups that fill from the bottom up! That of course would be lost in static SVGs.

Things get even more complicated, because the variable font, in the lighter weights, standard corners smoothly transition to having rounded inner corners, while maintaining sharp inner corners in the regular weight and heavier. Can the standard SVG stroke do that?

And then things get even more complicated than THAT, because when certain settings combine, in the corners of the design space, instead of doing straight vector addition, we warp the design space by adding what I refer to as “synthetic masters.” Basically taking a point inside the design space that has the characteristics we want, and “promoting” it to become the new corner master at a corner. The design has 14 real masters, but 12 additional synthetic masters. This allows us to decide that doing 100 weight and low grade and 48 px size all at the same time through vector addition will make our contours literally disappear, so let’s not do that—we have adjusted a whole bunch of combination points in that way.

So, it is just the slightest bit more involved than blindly adding a stroke to an outline.

[o-alexandrov]

Thank you for the reply. However, I’d rather see a pixel difference between two images than a view of an expert (humans make mistakes).

Could you please state a specific icon with specific weight from Material Icons (not Symbols) that you think would have the worst result when using as a parameterized SVG?

• it would then allow me, or anyone else, to compare pixel difference to the existing SVG from material-ui library

Then, we could make a factual assessment whether use of SVGs is truly unreasonable or it produces indistinguishable to human eyes difference.

[tphinney]

Obviously it depends on what your starting point is. Probably you could find a midline and make some icons match at the Thin weight, for some arbitrary combination of other settings.

But if you then try to generate the Regular weight from that skeleton by stroking, every single icon would fail to match, because of the differences in how the corners are handled, and the way that weight is not added evenly inside/outside, and so on.

Also, no stroking change can correctly take you from the 24 px master to the 20 px master or vice versa, when each of them is manually designed to fall precisely on the pixel grid. If you are taking a skeleton and stroking it, and generating as SVGs, either all your 24 px icons will look fuzzy, or all your 20 px icons will look fuzzy. We just spent a big chunk of the last eight months or so revising the 20 px masters to be grid-snapped based on manually tweaked pixel patterns and outlines.

Please, also do go read up on “faux bold” algorithms for text, and how they do not match real bold designed fonts. Are there SOME users who can’t tell the difference? Sure. But most do. To designers it is obvious. And to typographers it is painful to see.

And at this point no, I am not going to spend a couple more hours creating graphics to prove that your idea is flawed. I already spent an hour explaining why. Sorry, I have actual work to do.

If you are so sure this solution is viable, then please try it yourself and show the results. Specifically show how your stroke effect matches the Thin, Regular and Bold weights, for the “delete” and "calendar_view_week" icons, at 20 and 24 px.