Bidirectional text support with something like a PreTextRenderer

[andreialecu]

It would be really nice to support mixed-script text better in this repo.

Looking at chenglou/pretext, the readme mentions it can render text to WebGL. That made me wonder if it could maybe be used here as the basis for a new text renderer, something like PreTextRenderer or similar.

This could be useful for cases where text includes multiple scripts in the same string/component, and might help with broader i18n support too.

Maybe worth exploring:

• whether pretext could plug into the existing text rendering setup
• whether a separate renderer like PreTextRenderer would make sense
• what the limitations would be (I see it needs Intl.Segmenter which is Chrome 87+)

Repo:

• chenglou/pretext

[andreialecu]

Relevant: chenglou/pretext#12

[chiefcll]

What are you hoping to get out of this that isn't currently handled by the SDF renderer?

Major blocker is that this library won't work in Chrome 38 devices (so most devices wouldn't be able to use this)

[philippe-wm]

pretext supports bidirectional (think Arabic, Hebrew) text layout. For that it uses the very modern Intl.Segmenter. I've been thinking about potentially hack-polyfilling it with the bidirectional-capable tokenizer in Lightning 2.

Note that it itself isn't sufficient for Arabic in SDF as it also requires ligatures support.

[andreialecu]

What are you hoping to get out of this that isn't currently handled by the SDF renderer?

Major blocker is that this library won't work in Chrome 38 devices (so most devices wouldn't be able to use this)

Basically, mixed script text, where part is latin and part is arabic or hebrew for example. It can occur naturally in some text we're rendering (outside of our control).

[andreialecu]

Regarding Chrome 38, I think those are quite old by now. Chrome 38 is on TVs from 2017 (https://webostv.developer.lge.com/develop/specifications/web-api-and-web-engine)

However, there could be a fallback where Chrome 38 just uses CanvasTextRenderer. Mixed script works with it already.

My current workaround is to route strings with non-Latin characters to CanvasTextRenderer and others to SDF renderer.

Here's what I'm doing:

const rendererOptions = {
  appWidth: 1920,
  appHeight: 1080,
  renderEngine: WebGlRenderer,
  fontEngines: [SdfTextRenderer, CanvasTextRenderer], 
  // ...
};

// SDF — Noto Sans MSDF atlas (Regular/SemiBold/Bold)
loadFonts(SDF_FONTS);                        // family: "Noto Sans"

// Canvas2D — Noto Sans Latin woff2 via @fontsource; OS cascade covers the rest
void renderer.stage.loadFont('canvas', {
  fontFamily: CANVAS_FALLBACK_FAMILY,        // "Noto Sans Canvas"
  fontUrl: notoSansLatinWoff2,
});

// Auto-generated by scripts/gen-msdf-fonts.mjs — DO NOT EDIT.
// Codepoints baked into the NotoSans MSDF atlas. The design-system
// <Text> wrapper checks each label's codepoints against this set:
// covered → SDF (crisp), anything else → Canvas2D (browser cascade).

export const SDF_COVERED_CODEPOINTS: ReadonlySet<number> = new Set(
  '32,33,34,35,...'.split(',').map((s) => Number(s)),
);

function pickFamily(s: string): string {
  let i = 0;
  while (i < s.length) {
    const cp = s.codePointAt(i)!;
    if (!SDF_COVERED_CODEPOINTS.has(cp)) return FAMILY_CANVAS; // → "Noto Sans Canvas"
    i += cp > 0xffff ? 2 : 1;
  }
  return FAMILY_SDF;                                            // → "Noto Sans"
}

import { Text } from '../design-system/Text';

// Latin → "Noto Sans" → SDF (crisp, GPU-fast)
<Text fontSize={32}>BBC News</Text>

// Arabic → first codepoint U+0627 misses the atlas
//        → "Noto Sans Canvas" → Canvas2D
//        → ctx.font = "Noto Sans Canvas, sans-serif"
//        → browser cascades to OS Arabic face (Geeza Pro / Noto Naskh Arabic)
<Text fontSize={32}>الجزيرة</Text>

// Mixed → one out-of-atlas codepoint forces the WHOLE label to Canvas
<Text fontSize={32}>BBC الجزيرة 24</Text>

[philippe-wm]

It's important to double check what you're trying to do: rendering a single Arabic word isn't the same as rendering sentences and it will definitely break if you wrap text. Blits text renderer is really not capable of reliably render bidirectional text

[andreialecu]

I've been thinking about potentially hack-polyfilling it with the bidirectional-capable tokenizer in Lightning 2.

FWIW there is a polyfill here, not sure how performant though: https://formatjs.github.io/docs/polyfills/intl-segmenter/

[philippe-wm]

Seems to be 145kb for segmenter (Intl polyfills generally are quite large) plus 48kb for pretext, which is not great but not terrible
https://bundlejs.com/?q=%40formatjs%2Fintl-segmenter%2Fpolyfill.js%2C%40chenglou%2Fpretext%400.0.7&treeshake=%5B*%5D%2C%5B*%5D