Style properties for text shaping

[wipfli]

@alanchenboy is working on text shaping with Harfbuzz in MapLibre Native. This might be brought to GL JS with a plugin (harfbuzz wasm similar to the rtl plugin).

Now shaping might require new style spec properties like for example text-language. But they would only have an effect when the shaping plugin is loaded.

Is it OK to style spec properties that only work if the shaping plugin is loaded?

[HarelM]

I don't think so. The spec should work for the package without the need for a plugin.
Can you elaborate on why there would be a need for a spec change only for when using the plugin?
Or elaborate what this new property means?

[wipfli]

Browsers essentially do what @brawer summarized here: maplibre/maplibre-native#778 (comment)

An important difference between a browser and MapLibre GL JS is that the browser has access to system fonts that are stored on the client. So your website can for example contain Khmer and Chrome can render it even if you don't download a khmer.ttf font file...

[wipfli]

A lot of the complexity of text rendering has to do with the process of finding text segments that harfbuzz can render in one go.

For example, if you have the string "Zürich मुंबई" (Zürich Mumbai), then you have to split the string into two segments "Zürich " and "मुंबई" and call Harfbuzz with these segments and two different fonts.

Here is an example which shows what harfbuzz needs as input and what it gives you back as output: https://harfbuzz.github.io/a-simple-shaping-example.html

[wipfli]

My proposal would be to expose the parameters of Harfbuzz to the user. The user would have to cut the text into segments that harfbuzz can render.

So if you want to have "Zürich मुंबई" as a map label, you would use a format expression with the segments "Zürich " and "मुंबई" and the appropriate harfbuzz settings for each segment.

[HarelM]

I don't think that's a good idea, it's ok as a POC, or something to better understand how things work, but as a feature, expecting the user to do all this work isn't the right approach, IMHO.

[wipfli]

Yes, maybe there is a better and more automatic way to do this.

@alanchenboy in your implementation, you find all the harfbuzz input parameters (language, font, direction, script) from the text string alone, right?

[wipfli]

In the spirit of test driven development, I made a small test suite for text which MapLibre GL JS cannot render at the moment:

https://github.com/wipfli/i18n-testsuite-maplibre

[wipfli]

To come back to your questions @HarelM:

Are there smart defaults we can use? How does the browser do it without all this configurations when using HTML?

From the canvas labels in https://github.com/wipfli/i18n-testsuite-maplibre it looks like all what browsers need it the string. At least this seems to work well enough for map labels. So a solution in MapLibre should probably guess what the language, script, and direction are of a text string...