{fontstack} server requests: one or several when multiple fonts are specified?

[jlpoolen]

The MapLibre Style Spec defines a URL template which must include a {fontstack}, a token that is replaced "with a comma separated list of fonts from a font stack specified in the text-font property of a symbol layer"

The text-font specification, in turn, requires a text-field or an "Optional array"

A stylesheet can specify a glyph in this manner:

"glyphs": "http://debian1/MapLibre/local/fonts/{fontstack}/{range}.pbf",

So a directory on a server running Apache and having this tree of font files exposed:

jlpoole@debian1:/usr/local/src$ tree openmaptiles/data/fonts |nl
     1  openmaptiles/data/fonts
     2  +-- Noto Sans Bold
     3  |   +-- 0-255.pbf
... [other pbf files]
   258  |   +-- 9984-10239.pbf
   259  +-- Noto Sans Italic
   260  |   +-- 0-255.pbf
... [other pbf files]
   515  |   +-- 9984-10239.pbf
   516  +-- Noto Sans Regular
   517      +-- 0-255.pbf
... [other pbf files]
   772      +-- 9984-10239.pbf
       
   773  4 directories, 768 files
jlpoole@debian1:/usr/local/src$ 

would return the requested *.pbf file.

My question: when you have a font specification for a feature with more than one font specified, are separate requests generated to retrieve each font, or is the "fontstack" sent to the server to be parsed and the individual files therein returned?

Example:

A style sheet having the "glyphs" defined above has this specification for a water_way_name feature where two fonts are specified:

jlpoole@debian1:~/MapLibre/local$ head -n 3940 osm_openmaptiles_2_road_repairs_fonts8080.json|nl|tail -n 23
	  3918      {
	  3919        "id": "water_way_name",
	  3920        "type": "symbol",
	  3921        "metadata": {},
	  3922        "source": "openmaptiles",
	  3923        "source-layer": "waterway",
	  3924        "minzoom": 0,
	  3925        "filter": ["all", ["==", "$type", "LineString"]],
	  3926        "layout": {
	  3927          "text-font": ["Noto Sans Regular", "Noto Sans Bold"],
	  3928          "text-size": {"stops": [[11, 10], [13, 12]]},
	  3929          "text-field": "{name:latin}\n{name:nonlatin}",
	  3930          "visibility": "visible",
	  3931          "symbol-spacing": 400,
	  3932          "text-max-width": 5,
	  3933          "symbol-placement": "line"
	  3934        },
	  3935        "paint": {
	  3936          "text-color": "#4d80b3",
	  3937          "text-halo-color": "rgba(255, 255, 255, 0.8)",
	  3938          "text-halo-width": 1
	  3939        }
	  3940      },
	jlpoole@debian1:~/MapLibre/local$ 

Should there be two requests submitted to the server at http://debian1 for each of the "Noto Sans Regular" and "Noto Sans Bold" files or is there just one request which concatenates the array items, e.g. ' ["Noto Sans Regular", "Noto Sans Bold"]' into something like following?

`  http://debian1/MapLibre/local/fonts/Noto Sans Regular,Noto Sans Bold/0-255.pbf`

[HarelM]

You can check the network tab and see...

[jlpoolen]

You can check the network tab and see...

Yes, rather than the network tab, I have preserved from my console:

An error occurred: Error: AJAXError: Not Found (404): http://debian1/MapLibre/local/fonts/Noto Sans Regular,Noto Sans Bold/0-255.pbf

My question (at this time) is not what I get, but what should the JavaScript be doing? I am trying to learn what the code is intended to do to determine if this is a bug. The portion of the URL containing the spaces and comma, e.g. "Noto Sans Regular,Noto Sans Bold", is invalid under a standard Apache configuration. I'm not familiar with Node servers and perhaps they can take array-like URLs and parse them. But again, is this what the writers of the code intend?

[HarelM]

Intended is a strong word... This code was inherited from mapbox.
Since this is a very performant area in the code I would assume that this is a server side optimization requirement to allow getting more than one font file.
There's nothing illegal about this URL in terms server side request, as far as I know.

[jlpoolen]

Intended is a strong word... This code was inherited from mapbox. Since this is a very performant area in the code I would assume that this is a server side optimization requirement to allow getting more than one font file. There's nothing illegal about this URL in terms server side request, as far as I know.

RFC 3986 pages 12-13 bears on your opinion re: legality. I am unable to discern the statements made there, but reference them here for posterity. I do show that the white spaces are encoded as they come to my Debian Apache server, the comma is not -- again, I'm not sure if RFC 3986 requires encoding of the comma, too, but this is getting academic, as Apache sees the comma and thinks it is part of the path which it is not. Here's a screenshot of an incoming request for the font:

I see also note that the code @acalcutt pointed to was touched 2,5, & 7 years ago: https://github.com/maptiler/tileserver-gl/blame/master/src/utils.js#L202-L212 I'm not sure what the effective date of inheritance is and believe it to be around December of 2020 when the license was modified.

[acalcutt]

For the tileserver-gl history, this one seems most relevant to me. It almost describes your issue...
maptiler/tileserver-gl#32
maptiler/tileserver-gl@a0fbf7f

[wipfli]

Should there be two requests submitted to the server at http://debian1/ for each of the "Noto Sans Regular" and "Noto Sans Bold" files or is there just one request which concatenates the array items, e.g. ' ["Noto Sans Regular", "Noto Sans Bold"]' into something like following?

I think it makes only a single request and the name is as you have specified.

[acalcutt]

I think what happens is in your glyph url. where the {fontstack} is gets replaced with the fonts being requested. Maplibre replaces {fonstack} with a comma delimited list of the fonts, which is supposed to be a primary font with fallback fonts (sorry I could only find this mapbox source for that)

On the web server side, there is usually some code that picks the first available font and returns it. However, because you are using apache it has nothing to handle that and splt the requested fonts, so it is just looking for a folder called "Noto Sans Regular,Noto Sans Bold", which doesn't exist

[acalcutt]

Like I was mentioning in the other thread, in the case of tileserver-gl, it has code that takes the comma delimited list of fonts that maplibre requests, and basically returns the frst available

https://github.com/maptiler/tileserver-gl/blob/master/src/serve_font.js#L17-L29
https://github.com/maptiler/tileserver-gl/blob/master/src/utils.js#L202-L212 (this is where it splits the comma delimited fonts)

[jlpoolen]

Yes, your referenced to the utlis.js demonstrates that a server receiving the request must further process the URL. In which case, and out-of-the-box Apache instance is not going to correctly return the font files, if at all, when there is more than one font specified. This limitation on a standard server, or requirement of a server modification, should be documented, perhaps the specification? The specification of allowing more than one font necessitates special handling as demonstrated by the tileserver-gl code: isolating comma-delimited values.

[HarelM]

Feel free to open a PR to the style_spec repo to improve the glyphs documentation. I agree it should be mentioned.
https://github.com/maplibre/maplibre-style-spec/blob/765e52c36ffe3d1a6edec722df6d7081ee889706/src/reference/v8.json#L137

[wipfli]

The font fallback thing tends to come up from time to time in the slack channel too. @jlpoolen feel free to search in the maplibre slack channel for "font" for more info. Here is one link at least: https://osmus.slack.com/archives/C01G3D28DAB/p1708688784110809

And here is how martin handles glyph range requests: https://maplibre.org/martin/sources-fonts.html#composite-font-request

[wipfli]

Another place where you might want to add some documentation could be at the text-field https://github.com/maplibre/maplibre-style-spec/blob/765e52c36ffe3d1a6edec722df6d7081ee889706/src/reference/v8.json#L1809