Set pango language through ctx.lang

[mapmeld]

This would set pango's language through the Canvas context ( ctx.lang, docs: https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/lang )

My goal was to fix issues where the same Unicode codepoint should appear differently in Simplified Chinese, Traditional Chinese, and Japanese (as an example: lang=zh 门 vs. lang=ja 门). This can be done with language-specific fonts, but modern fonts often support all options and use the lang tag.
Han unification: https://en.wikipedia.org/wiki/Han_unification
Related issue for Chrome client-side canvas: mapbox/tiny-sdf#58

I'm submitting the code and test as a draft PR because this is still failing to change the output.
I did rebuild bindings, and tried with and without pango_cairo_update_layout.
Other ideas: this is failing to set the language, setting it at the wrong time, the fonts or something needs to be reset, or pango handles Han unification using something else? I'm a longtime node-canvas user but new to the internals.
I found this reference to PANGO_LANGUAGE and %PANGO_SCRIPT_HAN https://github.com/gtk-rs/gir-files/blob/main/Pango-1.0.gir#L11631

[1ec5]

Should this call pango_context_get_language() for consistency with PANGO_LAYOUT_GET_METRICS? This would avoid the need to maintain lang as parallel state in canvas_state_t.

node-canvas/src/CanvasRenderingContext2d.cc

Line 46 in 0d3abd3

pango_context_get_language(pango_layout_get_context(LAYOUT)))

[mapmeld]

makes sense, done ✅

[chearon]

With the second commit, I don't think ctx.save() and ctx.restore() will update ctx.lang, will it? It needs to be on the canvas_state_t.

[1ec5]

In that case, should PANGO_LAYOUT_GET_METRICS use the lang field instead of pango_context_get_language()?

[chearon]

The layout should be up-to-date there, but good call looking at that. I'll start a review with my thoughts...

[mapmeld]

maybe the better way to get the language before it is lazily committed?

if (state->lang == "") { // unchanged
  pango_context_get_language()
} else {
  pango_language_from_string(state->lang)
}

[chearon]

@mapmeld this does seem to work (using Source Han Sans, Super OTC):

source (change examples/font.js with this)

const fs = require('fs')
const path = require('path')
const Canvas = require('..')

const canvas = Canvas.createCanvas(320, 320)
const ctx = canvas.getContext('2d')

ctx.lang = 'zh'
ctx.font = '50px Source Hans Sans'
ctx.fillText('\u8FD4', 0, 70, 100)

ctx.lang = 'zh-HK'
ctx.font = '50px Source Han Sans'
ctx.fillText('\u8FD4', 0, 140)

ctx.lang = 'tc'
ctx.font = '50px Source Han Sans'
ctx.fillText('\u8FD4', 0, 210)

canvas.createPNGStream().pipe(fs.createWriteStream(path.join(__dirname, 'font.png')))

My impression has been that usually different fonts are shipped for different languages, but this should definitely be used more.

[chearon]

Need to also update the CHANGELOG.md,

[chearon]

Update on this comment:

My impression has been that usually different fonts are shipped for different languages, but this should definitely be used more.

I forgot that there are 2 ways lang works:

1. Font selection, wherein the language is used to remove other languages from a matching set of fonts from a family
2. The language is also an argument to the shaper. You can have a single font face that supports glyph switching through GSUB tables. I think that's what you're referring to in the OP.

I just tested that "fi" won't turn into a ligature with EB Garamond, and the language is set to Turkish. So (2) is definitely fixed. I'm not sure if the Source Han Sans test was (1) or (2). But if (2) works, I assume Pango would do (1) as well, so I'll call it working...

[chearon]

Thanks!