Subset icon font

[caperaven]

The icon font has all the icons available. I am looking for a way to customise or create a custom font that only contains the icons I use. What tooling do you use to create the current icon fonts?

I am kinda new to the font generation thing but would like to get the same behaviour as using the standard font. That being that the icon name is the identifier of the icon not some ascii code.

The intent of the custom font is for personal use but are there any legal issues I should take note of?

[EskelCz]

@tphinney Thanks for the explanation!

@tphinney could I impose on you to review rsheeter/subset-gf-icons#3? - looks to me like now if I subset Material Symbols to "star" it additionally retains "star.fill"

I works! Beautiful :)

You're a star :) Thanks a lot!

[tphinney]

Although I am happy to also inspect the font itself, I suspect the proof is in the visual output. If that is fixed, we can reasonably suspect that it is because the fully-filled alternate glyph is being called upon as intended. :)

[yisibl]

@rsheeter

About: rsheeter/subset-gf-icons#3

I'm trying to develop a web version and I'm having a little problem. hb-subset is not producing the same results as subset-gf-icons, can you share the full command for hb-subset or pyftsubset?

[yisibl]

I read the Python code for subset-gf-icons again, and I think I figured out that for the star icon, I should enter the command:

pyftsubset input.ttf --gids='4261,4995,5012,5013,5014' --output-file="ft.ttf" --verbose --glyph-names

There will be more 'atr', ' 'rtt', etc. in the output Glyph names than in subset-gf-icons, which will be permuted when pyftsubset is subsetted.

pyftsubset output

Closing glyph list over 'GSUB': 6 glyphs before
Glyph names: ['.notdef', 'a', 'r', 's', 'star', 't']
Glyph IDs:   [0, 4261, 4995, 5012, 5013, 5014]
Closed glyph list over 'GSUB': 12 glyphs after
Glyph names: ['.notdef', 'a', 'atr', 'r', 'rtt', 's', 'star', 'star.fill', 'stars', 'stars.fill', 'start', 't']
Glyph IDs:   [0, 209, 210, 2213, 2344, 2630, 4261, 4262, 4995, 5012, 5013, 5014]

subset-gf-icons output

Closing glyph list over 'glyf': 7 glyphs before
Glyph names: ['.notdef', 'a', 'r', 's', 'star', 'star.fill', 't']
Glyph IDs:   [0, 4261, 4262, 4995, 5012, 5013, 5014]
Closed glyph list over 'glyf': 7 glyphs after
Glyph names: ['.notdef', 'a', 'r', 's', 'star', 'star.fill', 't']
Glyph IDs:   [0, 4261, 4262, 4995, 5012, 5013, 5014]

@behdad @anthrotype For hb-subset and pyftsubset do we have parameters to do the same as subset-gf-icons? Or does the subset generated by subset-gf-icons need to be consistent with them?

[rsheeter]

hb-subset is not producing the same results as subset-gf-icons, can you share the full command for hb-subset or pyftsubset?

There isn't an exact equivalent, you'd have to make a new entrypoint that does what subset-gf-icons does. I'm not sure off-hand if the closure function you need is readily accessible; if not that might require a change to HB.

[yisibl]

@rsheeter I found the right way to go and should have used the --no-layout-closure flag. See https://github.com/harfbuzz/harfbuzz/issues/4192

pyftsubset input.ttf --output-file="ft.ttf" --gids="4261,4995,5012,5013,5014" --verbose --no-layout-closure
hb-subset input.ttf -o hb.ttf --gids='4261,4995,5012,5013,5014' --no-layout-closure

The difference between the current hb-subset and pyftsubset is that star.fill is not added.

[yisibl]

The original font avoids this Apple-rendering complication by being coded to substitute a completely filled glyph variant when Fill is >99%.

@tphinney Magic, do you mean that when the variable axis FILL = 99%, theoretically there shouldn't be a blank space in the middle of the icon?

Is it just that Apple's font rendering engine doesn't handle this extreme case very well?

My tests have found blanks in Chrome and Firefox on the Mac as well.

[tphinney]

Yes, that is about it, although technically the code sure looks like it says the alt glyph kicks in at GREATER THAN 0.99, so for example at 0.991 or higher fill, you should get a swap to the fully-filled version of the icon.

That is exactly the reason, that Apple’s rendering engine does not handle this well. But honestly the whole thing of having two filled glyph areas that are supposedly seamlessly abut each other… this is really NOT a normal font rendering expectation/situation at all. We are doing something pretty darn weird, and I really don’t blame Apple that their rendering does not deal with it well. That’s why I came up with the alternate glyph swap at >99% fill as a workaround. (At least, I think it was my idea. Most of the clever technical ideas on this were Vassil Kateliev’s, though!)

[yisibl]

@tphinney Thanks!

I found some rlig implementations, and I'm curious, which one does material-design-icons use?https://github.com/TypeNetwork/salon-variablefonts#feature-variations--alternate-layers

[tphinney]

Sorry I didn’t notice that last comment earlier.

We use 'rlig' two different ways — 1) we are using it for normal ligation behaviors, no weirdness involved, unlike what is described there 2) we also use it for what you would expect one to use 'rvrn' for, except that because the details of 'rvrn' are dumb, we can’t use it. Our particular build path uses UFO as described at https://github.com/TypeNetwork/salon-variablefonts#feature-variations--alternate-layers

[0smr]

Probably the ligatures are getting lost because you aren’t including the glyphs that are needed to input the ligatures. Besides the desired symbols you would need a-z, space, underscore, and to include the 'rlig' feature.

@tphinney Hi, I just want to say thank you, and I'm wondering if this is mentioned anywhere. If it's not, I'm not sure if it's a good idea, but I'm hoping to write it down somewhere in case someone encounters this issue, since most people may not read the whole thread. I spent three days figuring this out, and simply including a-z and underscore fixed the issue.