MBStyle font management can lead to "tofu" chars

Description

Rendering a multi-language map, reporting for labels both a latin name and, when available, a non latin one, results in the following:

 

This is due to the font translation taking the "text-font" property and using it as the font family name in SLD.
In fact, the Mapbox GL styles are not using regular fonts, but collections of glyphs saved in PBF files, and accessed via a URL template, as described at https://docs.mapbox.com/mapbox-gl-js/style-spec/#glyphs

In practice, the name in the font can be anything, and the range in the URL is dynamically determined based on the range of unicode code points to be rendered, making the client ask for multiple pbf files to get all the glyphs needed to render a particular label, on the fly. Being glyphs and not fonts, they also embed the notion of bold and italic inside the "font name", as that leads to different glyphs being saved.

The OpenMapTiles project provides tools to generate the glyphs PBFs based on some common multi-language fonts, it can be found in this GitHub project:
https://github.com/openmaptiles/fonts

The result for a particular font looks a bit as follows:

Basically, the folder contains all possible glyph files for "Noto Sans Bold", split in ranges of code points.
The above was generated from the full list of TTF files, covering the various scripts, and thus, the various sets of code points: https://github.com/openmaptiles/fonts/tree/master/noto-sans

In order to avoid generating tofu chars in the output, GeoTools needs to somehow go back to the list of TTF files, and list each of the fonts in Noto Sans in the SLD (here is a screenshot of how the OS sees the fonts, from the font chooser in LibreOffice):

Suggested approach, based on conventions:

  1. Parse the font name and extract the "Bold" and "Italic" qualifiers, moving them to the SLD ``font-weight`` and ``font-style`` properties (eventually via wrapper functions)

  2. List all the fonts in the system that start with the base name (e.g., Noto Sans) and list them all in the SLD, allowing the system to pick up alternative fonts when a char cannot be rendered with the main one (this will work only for static fonts)

  3. Keep on adding the fallback fonts already included in the code

As a more tricky alternative to point 2, just wrap the font name in a function that returns a List at runtime, based on dynamic inspection of the available fonts, and alter the renderer to deal with it (right now it expects a font-family entry to evaluate just to a String). Could be an interesting approach to reduce the number of fonts listed in manually written styles too.

do you think that's reasonable?

Environment

None

Assignee

Andrea Aime

Reporter

Andrea Aime

Triage

None

Components

Fix versions

Priority

Medium
Configure