Label in many tiles are not rendered when using fonts of browser

[Kanahiro]

maplibre-gl-js version: v3.5.2

browser: Google Chrome Version 118.0.5993.117 (Official Build) (arm64)

Steps to Trigger Behavior

1. load fonts in CSS
2. write style to load fonts in browser
3. many labes aren't shown. These are shown when use glyph-pbf

Link to Demonstration

https://jsbin.com/ragetuhoba/edit?html,output

Expected Behavior

• Two maps in above example should be same because they have same style and use same font.

Actual Behavior

• It looks like labels in "some tiles" are not rendered.
• It is strange also "circles" are not rendered.

[HarelM]

Can you inline only the relevant part of the style in the reproduction? Going over the entire style might prove problematic.

[Kanahiro]

Is it okay?

https://jsbin.com/ragetuhoba/edit?html,output

[Kanahiro]

I guess the problem is related to occur in following codes (actor.send('getGlyphs' ):

maplibre-gl-js/src/source/worker_tile.ts

Line 151 in 381b1de

if (Object.keys(stacks).length) {

I should understand "life of tile"...
https://github.com/maplibre/maplibre-gl-js/blob/381b1de9cff429be8cb69c769aafb602ce6158f7/developer-guides/life-of-a-tile.md

[HarelM]

I've just rewritten this whole area as part of a major refactoring I did.
If you plan to fix this, I suggest looking at the async-actor branch, the code there is a lot more readable, I think.
But yes, it sounds like these things might not work as expected for fonts that are not pbf style, we probably need to improve in that area, your help would be appreciated.

[Kanahiro]

Okay, I'll try it.

[HarelM]

Yes, I've seen some weird stuff in this code, also in the caching code I refactored in that same class, but I'm not familiar enough with all this logic there...

[Kanahiro]

I reached two:

1. the range of unicode as CJK is not enough:

   maplibre-gl-js/src/render/glyph_manager.ts

   Line 163 in 381b1de

   _doesCharSupportLocalGlyph(id: number): boolean {

   
   a. When the problem occurs, there are unicodes not included in that range.
2. when localIdeographFontFamily is truly and the above range problem occurs, any symbols are not rendered in a tile.

[Kanahiro]

the function _doesCharSupportLocalGlyph seems to have potenttialy problem.
For example, the example case is fixed by changing the range:

    _doesCharSupportLocalGlyph(id: number): boolean {
        /* eslint-disable new-cap */
        return !!this.localIdeographFontFamily &&
            (id < 256 || // Basic Latin
            unicodeBlockLookup['CJK Unified Ideographs'](id) || //19968 - 40959
            unicodeBlockLookup['Hangul Syllables'](id) || // 44032 - 55215
            unicodeBlockLookup['Hiragana'](id) || // 12352 - 12447
            unicodeBlockLookup['Katakana'](id) || // 12448 - 12543
            unicodeBlockLookup['CJK Symbols and Punctuation'](id)); // 12288 - 12351
        /* eslint-enable new-cap */
    }

I added Basic Latin and CJK Symbols and Punctuation.
However, if any other characters are included in a tile, same problem will occur. For example once a tile includes a character with basic latin, the problem will easily occur.

It is unclear for me why these codes consider only CJK text. These don't take into accont even Basic Latin.
So, IMHO, that function may not be needed but it depends on the reason why this function exists and consider only CJK unicodes.

At least, the range should depends on a font, not hard-coded.

[HarelM]

The reason for this is performance, it's a lot faster to use the pbf fonts, and since CJK are hard to achieve in pbf (as far as I understand, but I don't think I understand this enough) this was added. I think.
Cc: @wipfli @bdon

[bdon]

Unless there was changes to the internal actor logic between 3.4.1 and 3.5.2, I don't believe there is an issue here. If you are specifylocalIdeographFontFamily: ['serif'] along with a valid font (Noto Sans JP does not correspond to any font hosted at that endpoint, it still needs to fetch those glyph ranges for some non-character codepoints like whitespace) it works:

It might work if you have a font called Noto Sans JP installed on your computer but that is totally unreliable for end users.

[wipfli]

You might want to wait until your .ttf font is loaded before you create the maplibregl instance.

[Kanahiro]

Thanks eyeryone, I can understand the behavior.

https://github.com/wipfli/about-text-rendering-in-maplibre

This is very nice document for me!

Then, the problem seems to be in that once a font specified in style doesn't exist in local and server, rendering entire a tile not only labels would be stopped.

[1ec5]

I didn’t notice this existing bug report when filing #4563. #4564 contains a fix for this issue.