Symbols: Allow text line breaks on lines

[LostDragonist]

Resolves #3814

The change is pretty simple. The text shaper was explicitly disallowing any text breaks if the 'symbol-placement' was not set to 'point'. This removes that logic, allowing text breaks to be processed for any 'symbol-placement' value. The other bits are just removing the now unused variable from calling functions.

No new unit test as the text shaper unit test is sufficient now that it's not specifically avoiding the problem.

The only pain point in my mind is that someone may be relying on this behavior for some reason. There doesn't appear to be any property on symbol layers or any expressions that could be used to quickly change back to the previous behavior. Though I'd argue if you don't want explicit line breaks in your data, don't add explicit line breaks in your data?

For non-explicit line breaks, setting 'text-max-width' to a large number should get back to the previous behavior.

Before (string is "A\nBB\nCCC"):

After (string is "A\nBB\nCCC"):

Launch Checklist

• Confirm your changes do not include backports from Mapbox projects (unless with compliant license) - if you are not sure about this, please ask!
• Briefly describe the changes in this PR.
• Link to related issues.
• Include before/after visuals or gifs if this PR includes visual changes.
• Write tests for all new functionality. (none, see above)
• Fix / update all the affected render tests
• Document any changes to public APIs. (none)
• Post benchmark scores.
• Add an entry to CHANGELOG.md under the ## main section.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 25.00000% with 6 lines in your changes are missing coverage. Please review.

Project coverage is 85.08%. Comparing base (d7cd701) to head (2082f05).
Report is 3 commits behind head on main.

Files	Patch %	Lines
src/symbol/symbol_layout.ts	20.00%	4 Missing ⚠️
src/symbol/shaping.ts	33.33%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4124      +/-   ##
==========================================
- Coverage   86.88%   85.08%   -1.80%     
==========================================
  Files         242      242              
  Lines       33044    33040       -4     
  Branches     2011     1980      -31     
==========================================
- Hits        28709    28111     -598     
- Misses       3374     3856     +482     
- Partials      961     1073     +112     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[HarelM]

Thanks for taking the time to open this PR!
This seems intentional, any chance you can try and find the historical reason for this decision?
Also please add a changelog item and fix the tests.

[LostDragonist]

The history is a little interesting here.

A text-max-width of 0 used to be treated as a special value that meant "absolutely no line breaks." This also applied to explicit newlines like in the current issue. This was changed for 'point' placements in order to allow the explicit newlines. The reason 'point' was singled out is because text-max-width only applies to 'point' placements and is set to 0 otherwise (https://github.com/maplibre/maplibre-gl-js/blob/main/src/symbol/symbol_layout.ts#L159).

Going back a bit further, text-max-width applied to everything but 'line' placements. This seems to have to changed when 'line-center' was introduced (I think it was just 'point' and 'line' before that). This behavior seems to go back to the beginning.

Similarly, the "text-max-width of 0 means no line breaks" goes back pretty far. This was part of a very intentional change to make it so text didn't wrap on 'line' placements. It's possible disabling the line wrapping instead of setting the max width to infinity was preferred for performance reasons? Will need to run the benchmarks.

---

Given all that, I believe the best solution to solve the current issue and maintain most of the previous visual behavior is:

1. Change the forced/default 'text-max-width' for 'line' and 'line-center' placements from 0 to INFINITY.
2. Allow explicit line breaks to occur with 'line' and 'line-center' placements.

The style-spec should also probably be changed to specify that 'text-max-width' does not apply to 'line' and 'line-center' symbol-placements...?

[LostDragonist]

Benchmark results for a8c630e: all.pdf

Don't see anything that looks terribly amiss. I wouldn't expect any major performance issues with this issue. The infinity gets resolved to a Math.ceil( x / infinity) which JS can easily interpret as 0. A map with a lot of lines and 'line' or 'line-center' placements may see a small hit to performance.

[HarelM]

Thanks for looking into this!
Style-spec docs are residing in the maplibre-style-spec repo. Please open a PR there.
A render test with line break would be great here.
Also coverage of changed lines isn't great, some unit tests to cover the changes world be helpful.

[wipfli]

Thanks for opening this pull request. I found the behavior around newlines strange in the past and here you describe well what the situation is.

This pull request will make existing maps look different which is something we should avoid. Is it possible to introduce an new style spec property to take account of the line breaks?

[HarelM]

@wipfli I think we should also avoid complicating the style due to old bugs or missing implementation.
If people don't want to have new lines in the map they should make sure they don't have new lines in their data and not relay on something that is not implemented.
We can introduce this, assuming we think it's a breaking change, in a breaking change version (like we plan to for geometry-type).

[HarelM]

What will happen if the line is not straight? Like when adding a text to a river? What will happen in this scenario when adding a new line?

[LostDragonist]

Also coverage of changed lines isn't great, some unit tests to cover the changes world be helpful.

I've been trying to come up with unit tests for these changes but the symbol layout stuff is pretty complex. Any test I would write here is just a test for the purpose of getting coverage and would not be a useful unit test. I don't see this as benefiting anyone for what is essentially removing an unused variable in function calls.

What will happen if the line is not straight? Like when adding a text to a river? What will happen in this scenario when adding a new line?

Test string: "abcde\nfghijkl abcdefghijkl"
Before:

After:

It works about as well as it did before. Text along jagged lines has always been a bit weird. The only real added complication here is that 'text-justify' seems to be forced to 'center' when putting text along a line.

[wipfli]

Since this is a breaking change I suggest we go into pre-release mode of MapLibre GL JS v5.

[wipfli]

@HarelM can you open a js-parity issue in MapLibre Native for this change?

[HarelM]

@louwers, I'm delegation opening the feature parity issue to you.

[louwers]

@wipfli @HarelM Created issue and added it to the Render Test Parity Status Report