text-to-sdf expression

[wipfli]

I wonder if it would make sense to add a style spec expression called text-to-sdf which takes a string, renders it in a canvas and turns the image into an sdf.

A use-case would be:

"text-field": "Bangladesh",
"icon-image": ["text-to-sdf", "বাংলাদেশ"]

With this, we could do stuff like this:

What do you think?

[HarelM]

What problem does this solve? If the problem is with the current support of text, then it would probably have the same problems.
A use case I can think of, which I tend to think should have a better solution, is for text that follows streams, where the letters get messed up instead of following the steam curves. So this feature will allow keeping the text straight (a better implementation would be to following a straight line between two points on the stream basically).

[HarelM]

Sounds like a solution for a specific platform, isn't it?

[wipfli]

Canvas is web specific, right. Let me see if mobile operating systems have something similar which lets you turn text to pixels...

[1ec5]

Yes, every platform has an analogue. For example, on iOS, a UIGraphicsImageRenderer works very much like a canvas on the Web. You’d use Core Text APIs to render text using system fonts, just as gl-native does when generating CJK SDFs.

But @HarelM has a good point that this approach fundamentally only works for point features where you can reasonably hard-code the image’s dimensions at design time. Line-placed labels are important in any map that provides more detail than a city locator map. Another downside is the inability to reuse rasterized labels, leading to bloat in the internal spritesheet. And the drawing function doesn’t have enough context to rotate or tilt labels if the label needs to align to the map instead of the viewport.

styleimagemissing is a workable solution for rendering route shields because they are inherently point features that align with the viewport. But the issue of spritesheet bloat still comes up anyways.

In my opinion, the lack of built-in complex text support is problematic enough that any solution, however limited, deserves consideration for the benefit of the affected language communities. However, this feels to me like a workaround to be published as a plugin or example rather than a well-integrated solution.

[wipfli]

Yes maybe it would be best if I started with a plugin! I have never written one, do you have an example I could follow?

[1ec5]

mapbox-gl-language is a good example of a plugin that’s all about runtime styling.

[wipfli]

Using a canvas in web browsers would mean that the text does not look identical on all devices. Is this a requirement which we can drop for the sake of being able to render at least something in currently non-supported languages?

[wipfli]

Collisions are broken, and long labels look not great, but still, here is an example with street names in Bengali:

https://wipfli.github.io/maplibre-canvas-labels/offscreen#map=14.98/23.75498/90.38573

[ramSeraph]

Uh, nice, thanks for the Intl.Segmenter hint! It seems to actually work better than this javascript library I posted above:

According to the grapheme splitter readme, the js library splits

अनुच्छेद into अ + नु + च् + छे + द

whereas I find that IntlSegtmenter splits

अनुच्छेद into अ + नु + च्छे + द

To me, the Intl.Segmenter splitting looks much closer to the original...

This looks quite good. I hope firefox gets the Intl.Segmenter soon.

[wipfli]

https://github.com/wipfli/index-by-grapheme

[wipfli]

We can also segement by word:

         const segmenter = new Intl.Segmenter(
-             'en', {granularity: 'grapheme'}
+             'en', {granularity: 'word'}
         );

Here is a demo: https://wipfli.github.io/index-by-grapheme/by-word/#map=4.81/16.04/82.31&language=te

[wipfli]

For Burmese, one might want to use granularity: 'sentence'. Maybe we can let the user decide which granularity to use...

[1ec5]

Word and sentence segmentation is even more dependent on the text’s locale, which this code doesn’t have access to. Anything beyond grapheme cluster would behave similar to not segmenting at all (what you had tried originally): it would look disjointed and bloat the glyph texture.

[wipfli]

New idea: We could let the user decide how to segment text. The user could insert some sort of special character at the locations where text can be segmented.

Examples:

• Siem Reap (Khmer):
  • សៀមរាប
  • សៀ + ម + រា + ប
• Dubai (Arabic):
  • Dubai دبي
  • Dubai د + بي
• Crescent Lake (Bengali):
  • ক্রিসেন্ট লেক
  • ক্রিসে + ন্ট + + লে + ক
• Bogale (Burmese):
  • ဘိုကလေးမြို့
  • ဘို + က + လေး + မြို့

[wipfli]

I don't know how to do the segmentation for every language correctly, but I think there must be ways. And if we do the segmentation at tile-generation time, we can use as many libraries and as much compute as we want...