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.

[HarelM]

I have a similar use case, but using local glyphs folders with the relevant fonts is behaving as expected, for Latin and Hebrew only though.

[spatialillusions]

I solved it!
Let me just clean up my dirty JavaScript and I will share it, but the base concept is a custom protocol for glyphs, that calls my code that uses pbf and tiny-sdf to create glyph-ranges in the browser and hand them back to maplibre as if they were pbf files loaded from a server or disk.

[spatialillusions]

Dumped my code here:
https://github.com/spatialillusions/maplibre-local-glyphs