Intent to Prototype: Canvas Formatted Text

[Sushanth Rajasankar]

Contact emails 

sush...@microsoft.com, tra...@microsoft.com 

Explainer 

 
https://github.com/WICG/canvas-formatted-text/blob/main/README.md 

Specification 

None 
 

Summary 

Easily render multiline formatted text in Canvas, while letting the browser handle the hard parts of line-breaking and other language-specific constraints. 

 
Blink component 

Blink>Canvas 

Motivation 

You have a paragraph of text. You want to write it to the canvas. Canvas only supplies fill/strokeText -- only line of text at a time. Where do you break your paragraph up? Doing this is JavaScript is hard and error prone. For example, the author must consider: where are the break opportunities between words or Graphemes? Break opportunities are based primarily on the Unicode Spec but also use dictionaries for languages like Thai and French that dictate additional line breaking rules. Other consideration include identifying grapheme clusters, handling Bidi text, proper text shaping and kerning.  

 

Luckily, the browser already has a powerful line breaking, text shaping component used for regular HTML layout. This feature enables authors to tap into the browser's layout feature while maintaining control over the layout of multi-line formatted text. 

 

Initial public proposal 

https://github.com/WICG/proposals/issues/3 
 

TAG review 

None 
 

TAG review status 

Pending 
 

Risks 

This feature exposes new functionality to the Canvas. Similar behavior is being exposed to the CSS Houdini Layout API. Our goal is to find a good balance in terms of design that harmonizes the two concepts. 

 

Interoperability and Compatibility 

None 

 
 
Gecko: No signal 
 
WebKit: No signal 
 
Web developers: No signals 

 
 

Is this feature fully tested by web-platform-tests? 

No 
 

Tracking bug 

https://bugs.chromium.org/p/chromium/issues/detail?id=1155764 
 

Link to entry on the Chrome Platform Status 

https://chromestatus.com/feature/5996048675766272  

[Sushanth Rajasankar]

Fixing the row for "Web Developer signals"

We do have positive signals from web developers, they are interested in adopting this API for both performance and correctness reasons

nhelfman · GitHub - Excel Online - Microsoft

bonmotbot (Igor Kopylov) · GitHub - GSuite - Google

Thanks,

Sushanth

---

From: 'Sushanth Rajasankar' via blink-dev <blin...@chromium.org>
Sent: Friday, December 4, 2020 4:36 PM
To: blin...@chromium.org <blin...@chromium.org>
Cc: Travis Leithead <travis....@microsoft.com>
Subject: [EXTERNAL] [blink-dev] Intent to Prototype: Canvas Formatted Text

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/MN2PR00MB060671AEFC6F81BCB9725037FDF09%40MN2PR00MB0606.namprd00.prod.outlook.com.

[Ashley Gullen]

This would be good for our game engine Construct 3 (www.construct.net) as well.

Our engine renders entirely to a canvas, and for displaying text we use the canvas text APIs. Since ~2012 we've had to maintain our own custom word wrap engine in JavaScript to handle multi-line text, and I doubt it does everything this proposal does especially with regards to break opportunities and bidi text, so it would be great if the browser could handle that for us. I do think backwards compatibility would be tricky though, as switching existing content to a different word wrap engine will probably result in unwanted differences, but there's not much that can be done about that.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/DM6PR00MB060336F0695308E30C6499C8FDCD9%40DM6PR00MB0603.namprd00.prod.outlook.com.

[Daniel Bratell]

It does indeed sound like a good idea to leverage the browser's advanced line wrapping capabilities!

One friendly recommendation, don't wait too long with filing tag reviews and getting platform tests together, because I think this is something where there might be some discussions before everyone agrees on the best API surface.

/Daniel

[Sushanth Rajasankar]

Thanks Bratell, that is a good suggestion. We will follow up with the TAG in the new year 🙂.

---

From: Daniel Bratell <brat...@gmail.com>
Sent: Thursday, December 10, 2020 10:44 AM
To: Sushanth Rajasankar <Sushanth....@microsoft.com>; blin...@chromium.org <blin...@chromium.org>
Cc: Travis Leithead <travis....@microsoft.com>
Subject: [EXTERNAL] Re: [blink-dev] Intent to Prototype: Canvas Formatted Text

 

[Sushanth Rajasankar]

Thanks, Ashley. I'm excited to see that we can help simplify code and address your use case. Looking forward to your feedback once we have a prototype in Chromium.

---

From: Ashley Gullen <ash...@scirra.com>
Sent: Wednesday, December 9, 2020 2:53 AM
To: Sushanth Rajasankar <Sushanth....@microsoft.com>
Cc: blin...@chromium.org <blin...@chromium.org>; Travis Leithead <travis....@microsoft.com>
Subject: [EXTERNAL] Re: [blink-dev] Re: Intent to Prototype: Canvas Formatted Text

 

[Frank Tang]

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

1. multiple lines of text rendering in <CANVAS>
2. jsPDF and other context which need to layout text into multiple lines
3. 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

1. Instead of adding that to ECMA402 as a low level API, leave that part of job (breaking text into multiple lines of text) to Houdini 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
2. TC39 add such low level API into ECMA402 to allow developers to use that with the currently defined Houdini APIs, OR
3. TC39 add such low level API into ECMA402 to allow Houdini to depends on Intl.Segmenter for the job of finding out linguistic line break opportunity.

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

Similar question to you- do you think the enhancement to Intl.Segmenter will be conflict or redundant to your API? or will it complement the API you intend to implement? 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BYAPR00MB059824555DAD1801B8F6933AFDC79%40BYAPR00MB0598.namprd00.prod.outlook.com.