You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
Update and rename getRTLTextPluginStatus, clearRTLTextPlugin, setRTLTextPlugin, downloadRTLTextPlugin, and lazyLoadRTLTextPlugin to remove traces of RTL and allow using multiple plugins instead of a single one.
Change SymbolBucket::populate to support checking the status of multiple plugins
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.
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
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.
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 as66%
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
TextPlugin
interface that follows theplugin
structure defined inrtl_text_plugin
. One annoying caveat here is that the current implementation executes a function calledapplyArabicShaping
which is quite centered around RTL text. My proposal here would be to support using eitherapplyArabicShaping
, to keep backward compatibility with current plugins, or a more genericapplyTransformation
for newly developed ones.getRTLTextPluginStatus
,clearRTLTextPlugin
,setRTLTextPlugin
,downloadRTLTextPlugin
, andlazyLoadRTLTextPlugin
to remove traces ofRTL
and allow using multiple plugins instead of a single one.SymbolBucket::populate
to support checking the status of multiple pluginstransformTextInternal
intransform_text.ts
to runapplyTransformation
orapplyArabicShaping
on each plugin, one at a time, following the definition orderCompatibility
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
The text was updated successfully, but these errors were encountered: