Use TinySDF to generate missing glyphs in the client

[wipfli]

Sometimes a font file does not contain a glyph. Say for example that you have a font which covers a-z and A-Z but nothing else. Then if you want to render Zürich, the default behavior of MapLibre GL JS is to show Zrich I think. So it just skips the missing ü. In such cases where a glyph is missing from the font, we could generate it dynamically in the client with TinySDF.

[wipfli]

What do you think? cc @1ec5 and @ZeLonewolf because I think you spent quite some time putting a font together which has maximal coverage for Americana...

[ZeLonewolf]

I don't think I'm smart enough on font issues yet to offer an opinion here.

[1ec5]

Your assumption is correct: osm-americana/openstreetmap-americana#850 has some examples of what happens when the glyph PBFs lack required glyphs.

From an end-user perspective, your proposal is good for basic usability, assuming that the text-field value isn’t garbage. From a developer perspective, I don’t see a backwards compatibility issue at a glance, but it deserves a deeper look. Font selection is already so complex that preserving compatibility with Mapbox software might be somewhat important.

The traditional fontstack model always seemed unreasonable to me, especially that the fontstack would get flattened on the server side into a single set of PBFs, requiring the style to specify a pan-Unicode, last-resort fallback font as part of the fontstack. A last-last-resort fallback on the client side would reduce the dependency on fontstacks, getting us closer to the point where we can ditch that concept and, along with it, the faulty assumptions in maplibre/maplibre-native#778 (reply in thread).

As a side benefit, if developers who roll their own glyph PBFs can assume a version of MapLibre that has the proposed behavior, then they can roll much smaller PBFs that contain only the characters from specialty fonts and none of the fallback characters from boring pan-Unicode fonts. But a bit of caution is warranted: whenever a combining character’s font mismatches the surrounding text’s font, text layout always gets wonky.

[1ec5]

A last-last-resort fallback on the client side would reduce the dependency on fontstacks, getting us closer to the point where we can ditch that concept and, along with it, the faulty assumptions in maplibre/maplibre-native#778 (reply in thread).

Related: #4564, #4550, 1ec5#1, osm-americana/openstreetmap-americana#1149.

[spatialillusions]

I have a special use case where I run maplibre offline as a single HTML page reading a pmtiles file, for me it would be great if I just could use local fonts instead of having to make sure to copy all glyph files to the clients. At the moment I have made sure to include some char sets into the source and a custom protocol for reading them, but there are always some some glyphs missing.
Can't wait until this is merged into maplibre.

[spatialillusions]

Now available as a NPM package.
https://www.npmjs.com/package/maplibre-local-glyphs
Please let me know if it works for you.

[HarelM]

Interesting, I'll see if I can use that to replace the sprite as well.

[spatialillusions]

I have another solution for spirits where I store them as base64 encoded strings. Ping me on the email on my profile if you would like the source code. (It's a bit rough.)

[HarelM]

No, I'm storing the icon of my site in a font, like what's done in font-awesome.
So this might be a way to share icons between the map and the website.

[HarelM]

Also it's probably worth adding this plugin to awesome-maplibre repo so that it will appear in the docs and elsewhere.