Proposal: Support custom text transformation plugins

[ibesora]

Motivation

Allowing people to format labels as they want without having to transform their data in external software is quite limited using Maplibre style expressions. Things like having a number like 0.66 in the underlying data and wanting it to show as 66% are not supported right now. This proposal aims to fix that gap.

While style spec could be extended to support more text transformations, it's arguably impossible to support everything a developer might need and adding support for new transformations would require a new style spec version.

Proposed change

Add a new API to Maplibre that replaces the current RTLTextPlugin one for a more generic one to support arbitrary text transformation plugins. RTLTextPlugin must still be supported as it is by this new API.

API Modifications

1. Create a new TextPlugin interface that follows the plugin structure defined in rtl_text_plugin. One annoying caveat here is that the current implementation executes a function called applyArabicShaping which is quite centered around RTL text. My proposal here would be to support using either applyArabicShaping, to keep backward compatibility with current plugins, or a more generic applyTransformation for newly developed ones.
2. Update and rename getRTLTextPluginStatus, clearRTLTextPlugin, setRTLTextPlugin, downloadRTLTextPlugin, and lazyLoadRTLTextPlugin to remove traces of RTL and allow using multiple plugins instead of a single one.
3. Change SymbolBucket::populate to support checking the status of multiple plugins
4. Change transformTextInternal in transform_text.ts to run applyTransformation or applyArabicShaping on each plugin, one at a time, following the definition order

Compatibility

Supporting applyArabicShaping in plugins would allow this proposal to keep compatibility with existing plugins. No migration is needed.
There might be concerns about people writing arbitrary javascript code that can tank the performance but this can also be an issue currently.

Rejected Alternatives

There's a similar proposal to handle this in maplibre/maplibre-style-spec#516 by defining external functions in Maplibre's style spec. Doing that would couple the style definition with the website's code which this proposal avoids.

cc @ChrisLoer

[HarelM]

We have recently made a huge refactoring to the rtl text plugin to split worker code and main thread code.
I think an initial POC would be to try and present a different plugin that works similarly to how rtl text plugin works.
Once this is in place we can decide how to adapt the API to support multiple plugins.
The code in the worker can be changed to support more than the shape arabic method to avoid the need keep this "legacy" name.
Generally speaking, this sounds like a good hook.
A good example of how to write such a plugin is critical for this to work. We could add it to the developer guides.
Cc: @zhangyiatmicrosoft

[wipfli]

Interesting idea @ibesora. I would leave the RTL plugin interface in place and add a second interface for generic text transformation plugins. Both can use the same functionality internally.