1943070 - Canvas2D: Add support for the lang attribute in CanvasTextDrawingStyles

Status: RESOLVED FIXED

(Core :: Graphics: Canvas2D, enhancement)

Description

[schenney]

Attachment: canvas-lang-test.html

Steps to reproduce:

HTML Canvas text does not provide any method to localize the language in offscreen canvas, but takes the language from the canvas element for DOM canvas. This results in incompatible text rendering between offscreen and DOM canvases.

A proposal has been made, https://github.com/mozilla/standards-positions/issues/1150, to add a lang IDL attribute to CanvasTextDrawingStyles.

There is a PR on the spec: https://github.com/whatwg/html/pull/10873

There is a request for position: https://github.com/mozilla/standards-positions/issues/1150

Actual results:

See the example attached to https://github.com/mozilla/standards-positions/issues/1150. The glyph used for offscreen are always from the documents' content language, while the canvas element uses the elements language.

Expected results:

It should be possible to control the language for canvas text rendering.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Graphics: Canvas2D' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Calixte Denizet (:calixte)]

Jonathan what would be the effort to implement such a feature ?

Comment 3

[schenney]

I implemented in Chromium. Testing was maybe the biggest part of the job but the WPT now exist. The sub tasks are:

• Update the canvas idl.
• Add code for getter/setter and save/restore canvas state for canvas 2d.
• Make use of the lang string when canvas fonts are updated.
• Add the lang attribute to the set of attributes that are captured for a transferred offscreen canvas
• Add code to handle the "inherit" value for the 3 cases: regular 2D canvas, offscreen with canvas host, and offscreen in a worker.

I think that's it.

Comment 4

[Jonathan Kew [:jfkthame]]

Yes, this seems like it should be fairly straightforward, as outlined in comment 3.

(Does the spec consider how to deal with a value that is not a well-formed BCP 47 tag? In the text preparation algorithm, I see step 6: "If language is the empty string, then set language to explicitly unknown." Should that also be done if language is not a well-formed BCP 47 language tag?)

Comment 5

[schenney]

The canvas portion of the spec has nothing to say about malformed BCP 47 tags. When implementing I made canvas behave the same way as regular HTML content, where the spec says that an invalid tag must be retained as a unique unknown language (https://html.spec.whatwg.org/multipage/dom.html#the-lang-and-xml:lang-attributes).

When it comes to what font to use in that case the spec says nothing and the chromium implementation ultimately seems to rely on harfbuzz to give some reasonable font.

Comment 6

[Jonathan Kew [:jfkthame]]

I've put up a patch for this at https://phabricator.services.mozilla.com/D289096, but currently phabricator seems to be stalled and it's still in "draft" state. Hopefully that will be resolved soon and we can get this reviewed.

Comment 7

[Jonathan Kew [:jfkthame]]

Attachment: Bug 1943070 - Support the 'lang' attribute in CanvasTextDrawingStyles. r=#gfx-reviewers

Comment 8

[Jonathan Kew [:jfkthame]]

This is documented at https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/lang, but currently shown as unsupported in Firefox.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/938bd0bb8bab
https://hg.mozilla.org/integration/autoland/rev/47495a0c3043
Support the 'lang' attribute in CanvasTextDrawingStyles. r=gfx-reviewers,webidl,lsalzman,smaug

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/30885d5ddd99
https://hg.mozilla.org/integration/autoland/rev/d2a3d092ed23
Revert "Bug 1943070 - Support the 'lang' attribute in CanvasTextDrawingStyles. r=gfx-reviewers,webidl,lsalzman,smaug" for causing wpt failures @idlharness.any.worker.html.

Comment 11

[agoloman]

Backed out for causing wpt failures @idlharness.any.worker.html.

• Backout link
• Push with failures
• Failure Log

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/8fe347f255d6
https://hg.mozilla.org/integration/autoland/rev/e9ec306d6563
Support the 'lang' attribute in CanvasTextDrawingStyles. r=gfx-reviewers,webidl,lsalzman,smaug

Comment 13

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/e9ec306d6563

Comment 14

[Hamish Willee]

FF151 MDN work for this can be tracked inhttps://github.com/mdn/content/issues/43865.

The docs look good and the compat data has already been updated, so this should just be an MDN release note.

Comment 15

[Hamish Willee]

Could I please have some confirmation of part of the MDN docs on this? The docs say:

Due to technical limitations, the inherit value behaves differently for on-screen and off-screen canvases:

• For on-screen canvases, the lang value is inherited when the associated CanvasRenderingContext2D object is first created; the inherited lang value then changes dynamically if the lang attribute value is updated.
• For off-screen canvases, the lang value is inherited when the associated OffscreenCanvasRenderingContext2D object is first created, and then fixed for the lifetime of the OffscreenCanvas. It does not change if the lang attribute value is updated. Because of this, the language of an off-screen canvas can only be changed by setting the lang value explicitly.

The main point is clear - on screen canvases inherit their lang value on creation from their associated <canvas> or its nearest ancestor, and this attibute will update if the source attribute changes.

1. For offscreen canvasses I THINK this is saying that
   • the lang value is also inherited on creation,
   • but since there is no associated canvas it gets the lang of the document - right?
   • that value is not updated if the document lang changes, or if the offscreen canvas is associated with a canvas later that has a different lang value
   • But you can still change the value manually be setting the lang attribute.

Right?

Comment 16

[Hamish Willee]

@Emilio, I see the author was tagged for comment about 12 months ago. I need a confirmation relatively soon, so I'm adding you to the request to see if you can help with ^^^, or have a suggestion who might?

Comment 17

[Jonathan Kew [:jfkthame]]

(In reply to Hamish Willee from comment #15)

1. For offscreen canvasses I THINK this is saying that
   • the lang value is also inherited on creation,
   • but since there is no associated canvas it gets the lang of the document - right?

If created directly using the OffscreenCanvas constructor, yes. But if it is created from a canvas element using the transferControlToOffscreen method, I believe it'll inherit its lang from that element (rather than from the document); see also the HTML spec.

Comment 18

[Hamish Willee]

(In reply to Jonathan Kew [:jfkthame] from comment #17)

(In reply to Hamish Willee from comment #15)
...

If created directly using the OffscreenCanvas constructor, yes. But if it is created from a canvas element using the transferControlToOffscreen method, I believe it'll inherit its lang from that element (rather than from the document); see also the HTML spec.

Thanks @Jonathan.

I think you're right that the lang will come from the element for that method IF the element has a lang, and will otherwise inherit from the parent element and so on.
But if you look at the first example you point to the htmlCanvas doesn't have a parent element and hence no lang (I think it defaults to null.)

const htmlCanvas = document.createElement("canvas");
const offscreen = htmlCanvas.transferControlToOffscreen();

Above I said this would mean that the offscreen canvas got the lang of the root. If this is true, it means that there is some "magic" to get this from the document root - since the element in this case is never part of the DOM tree.

Anyway, I made a minor tidy to this in https://github.com/mdn/content/pull/44071/changes

Comment 19

[Hamish Willee]

Sorry, cancelling needinfo - that was more of an FYI

Comment 20

[Emilio Cobos Álvarez [:emilio]]

Hamish, FYI you needinfo?d the wrong Emilio there :)

Comment 21

[Hamish Willee]

Thanks @Emilio, my questions now answered - sorry for incorrect tagging.