Alternative glyph URL components to support HTTP only service

[bradh]

From https://maplibre.org/maplibre-style-spec/glyphs/

The URL must include:

• {fontstack} - When requesting glyphs, this token is replaced with a comma separated list of fonts from a font stack specified in the text-font property of a symbol layer.

This doesn't seem ideal for the case where the data is available on a simple HTTP service (e.g. using PMTiles with byte range requests). It still works for cases where there is no fallback (i.e. the font stack only has a single entry). However when there are two or more entries in the text-font array, the HTTP GET looks like https://server/fonts/font1,font2/0-255.pbf which is only going to work if that https://server/fonts/ is a API service endpoint, not a stack of files.

I'd like to be able to specify semantics for the glyph template to "use each font in the stack in turn", as opposed to "put the stack entries in here".

I couldn't find a previous discussion on this, but has it been considered? Any recommendations or thoughts?

[HarelM]

Thanks for taking the time to open this discussion!
I can't find it right now, but I believe this was discussed to some extent, maybe @1ec5 remembers where.
To summarize what I believe should be done here is less of a style spec definition change and more an implementation details.
I agree that making a request for two fonts to the backend this way is cumbersome.
I agree this should be done one after the other.
To prevent breaking changes we should probably still support the current behavior.
But I don't think the style spec definition should change as it defined well where to look for glyphs.

[bradh]

To summarize what I believe should be done here is less of a style spec definition change and more an implementation details.

I originally saw it as an implementation issue, although since the spec requires specific behaviour, I thought that probably needed to get updated first. I'm not really across the community norms, so it might be a bad assumption, but I couldn't really see an PR that changed behaviour being accepted when that behaviour is required in the spec.

[CommanderStorm]

I agree that making a request for two fonts to the backend this way is cumbersome.
I agree this should be done one after the other.

Counter-argument:

One request is faster than two requests.
Running a tileserver (f.ex. https://maplibre.org/martin/sources-fonts.html) is also not really more work than running a file server.

[bradh]

Counter-argument:

One request is faster than two requests. Running a tileserver (f.ex. https://maplibre.org/martin/sources-fonts.html) is also not really more work than running a file server.

In some environments its a lot more work. In particular, a HTTP file server is something that you can get delivered and supported / maintained pretty easily in most corporate or government environments (even if the IT people just outsource the problem to AWS or equivalent). A tileserver (or anything that isn't already on the Approved List) requires getting architectural approval for a new application, security paperwork and assessment, a new VM deployment, a change to the IT support contracts for installation and patching, management meetings, etc. I agree it isn't not really more technical work, but all that non-technical work is a good reason (well, my reason) to look for another way...

[HarelM]

I think you can simply create a file server with folder that match the entire font definition, this is what we did in the demotiles repo here:
https://github.com/maplibre/demotiles/tree/gh-pages/font

It's a hack, but one that works well.
Don't get me wrong, I too expect it to be a fallback list instead of a full url, but it's here to stay. See @1ec5 response below for more options to solve this, the linked PR just got merged and will be available with a new version within a week or two.

[bradh]

Cool hack. I will give that a try, thanks.

[1ec5]

The original design actually assumed the Mapbox Fonts API. We’ve all been getting lucky that it’s possible to emulate this API using a simple HTTP server. However, the more fundamental issue is that MapLibre doesn’t have the concept of font fallbacks at all when using server-side fonts: maplibre/maplibre-gl-js#4563. That’s why we treat the whole text-font value as a single token. The assumption is that the style author has enough control of the font server to ensure that the fontstack specified by the stylesheet does exist on the server.

Fortunately, text-font has the semantics you’re looking for when using local font rendering, such as with CJK fonts or when omitting the glyphs property altogether (see #1045). For the local font fallback in maplibre/maplibre-gl-js#4564, I’m still treating the whole text-font value as a single token when attempting to use a server-side font.

In principle, a further change to the style spec could allow text-font to be interpreted as a list of values even server-side. For backwards compatibility, the fonts would need to be fetched only after the existing attempt to treat it as a single value, or there would need to be a flag of some sort. Otherwise, we’d potentially be hammering the server with pointless requests. However, I’m assuming this will be less critical once local font fallback lands.