Wording alignment is off for terms in multiple scripts

[nicolasmaia]

See the example below for shops named "高輪saunas", "NEWoMan高輪LUFTBAUM", "THE CITY BAKERYニュウマンNorth"

[matkoniecz]

What is specifically wrong with alignment?

[nicolasmaia]

They should all be center-aligned within the text line, but as you can see in 高輪Saunas, Saunas looks like it's aligned to the top of the line. In the case of the bakery, the alignment seems kinda all over the place. The ニ looks lower than the preceding BAKERY, and in the next line, North looks higher than the preceding 高輪

[westnordost]

I think this is a font glyphs issue. For some reason, the glyphs for Japanese glyphs are bigger (using the same font size) on the map than latin letters. So, when mixed, you see the difference.

Unfortunately, I don't remember where we downloaded the glyphs in https://github.com/streetcomplete/StreetComplete/tree/master/app/src/androidMain/assets/map_theme/glyphs from, otherwise we could report this upstream.

@Helium314 do you remember? I think you were the one who had the idea to actually store the glyphs locally in order to workaround the maplibre bug maplibre/maplibre-native#2410, right?

[Helium314]

Unfortunately, I don't remember where we downloaded the glyphs in https://github.com/streetcomplete/StreetComplete/tree/master/app/src/androidMain/assets/map_theme/glyphs from, otherwise we could report this upstream.

Probably from https://github.com/kylebarron/openmaptiles-fonts/tree/master/fonts, see #5693 (comment)

@Helium314 do you remember? I think you were the one who had the idea to actually store the glyphs locally in order to workaround the maplibre bug maplibre/maplibre-native#2410, right?

Yes, it's also in the comments in the PR linked above.

[westnordost]

That repo looks like it was some one-time dump. Maybe we could check if the same issue occurs with downloaded glyphs from other sources. (If there are any)

[westnordost]

Source of the issue

So, the issue is that the font we use on the map (Roboto) doesn't actually have Chinese glyphs. From this font, other glyphs are missing too, such as Arabic, Japanese, Korean, Hebrew, Georgian, Armenian, all the various Indian and South East asian scripts, actually.

Why are then Chinese glyphs (etc.) displayed at all in the App, and on the map?

Well, Android has a fallback mechanism. If a glyph is not defined in Roboto, it will use the glyph from a different font family, Noto, instead.

MapLibre is separate from that. But it has a fallback mechanism, too. I have been told, however, that this fallback mechanism only works for Chinese/Japanese/Korean glyphs.

So, we uncovered a second issue: Labels in Arabic, Hebrew, Georgian, Armenian, all the various Indian and South East Asian languages will actually not show at all on the map! This is actually the bigger issue!

Solution

The best solution would be to ditch the (Roboto) font glyphs in SDF format altogether, and instead use the (relatively new) font-faces property in the map style that allows to just use a normal TTF font. Might be smaller, too.

Ideally, we should not bundle any font files with this app, but instead let MapLibre fall back to whatever system font the Android / iOS system falls back to.

However, @1ec5 told me that this is currently not possible due to at least maplibre/maplibre-native#165 . For me, it is also an open question whether solving the aforementioned issue would then allow being able to always simply fall back to the system font, as Android and iOS each use different font families as their default (fallback) font - Noto and San Francisco, respectively.

So, for the time being, the preferred solution to both issues is to use the font-faces property in the map style and define & provide a (Noto) font for all the unicode ranges we should support, manually.

Any help here would be appreciated.

[1ec5]

To be clear, maplibre/maplibre-native#165 is about the fact that the ostensibly optional glyphs property isn’t really optional if you intend to show any text on the map. Implicitly, it’s a request for MapLibre to perform font substitution beyond CJK, which I implemented on the Web in maplibre/maplibre-gl-js#4564 but haven’t ported to Android yet. (Happy to defer to any Android developer who’d like to pick up that work, as it’s mostly platform-specific.) Font substitution would mean that, if the text-field is absent or mentions an unavailable font by name, then MapLibre would fall back to the system’s default sans-serif font. This works in CJK but doesn’t work in other writing systems yet.

You could try specifying font-faces, but I think that mechanism might be limited to certain writing systems as well, so it might not be a solution for the screenshot above in Japanese. The root issue is that MapLibre’s glyph rasterizer has some unfortunate fudge factors to accommodate font metrics in glyph PBFs, which are inaccurate with respect to fonts rendered more natively on the client side.