Would ECMA402 Intl.Segmenter v2 proposal help/conflict/redudent w/ this work?

[FrankYFTang]

I am proposing an enhancement of Intl.Segmenter API (adding line break support) to TC39 for ECMA402 (see https://github.com/tc39-transfer/proposal-intl-segmenter-v2 ) The API expose "line break opportunity" of text which implement the
Unicode® Standard Annex #14 UNICODE LINE BREAKING ALGORITHM (see https://www.unicode.org/reports/tr14/)
so it can be used for developer to use it with

multitple line of text rendering in <CANVAS>
jsPDF and other context which need to layout text into multiple lines
SVG multiple lines of text
During the stage advancement discussion, one delegate suggest me to reach out to Houdini to see which one of the following is better

Instead of adding that to ECMA402 as a low level API, leave that part of job (breaking text into multiple lines of text) to your API to add such API to empower developers to use it on <CANVAS>, SVG , or for jsPDF and therefore there are no need to add them into ECMA402, OR
TC39 add such low level API into ECMA402 to allow developers to use that with your APIs, OR
TC39 add such low level API into ECMA402 to allow your API to depends on Intl.Segmenter for the job of finding out lingustic line break opportunity.

Please comment so we can move forward better in TC39 / ECMA402. Thanks

[travisleithead]

Frank thanks for filing. Just wanted to let you know that I've seen this and have been thinking about it. Will raise this with others in the community to see if they have opinions. My immediate response is that there could be room for both, but perhaps they are somewhat redundant in nature. (At least I hope the Formatted Text work could capture all the use cases that folks may want to line-break for 🙂.)