Render our own font stack

[ZeLonewolf]

This PR adds the ability to generate our own fonts and customize which glyphs are serviced by which fonts. Supports 173 languages.

Note that:

• CJK glyphs will fall back to system defaults
• Han Unification:
  • CJK Noto Fonts are bundled but not yet used. Additional work is needed to test for area and from that apply the appropriate CJK font. However, the default seems attractive enough
  • Additional work is need to identify other areas that need geography-specific fonts, e.g., see this discussion about the correct font to use in Pakistan: Recommendation to include additional Arabic Naskh fallback font gravitystorm/openstreetmap-carto#4644.
• Ligatures still don't seem to render how they should, but this is beyond the scope of this PR and may be an upstream issue.

[quincylvania]

Ligatures are affected by the context.textRendering property on Chrome. We should probably set this regardless of whether it fixes the problem, as leaving it on auto could lead to inconsistent results across browsers.

[claysmalley]

Huge step in the right direction! Well done.

The name of Providence in Hindi is प्रोविडेंस. A couple issues here:

• Ligatures are not forming. प्र (U+092A, U+094D, U+0930) is showing up in its non-combined form, प्‌र.
• Combining characters are appearing in the wrong visual order. व (U+0935) plus the vowel "i" forms वि (U+0935, U+093F). The combining vowel U+093F is joining with the following character instead.

Similar issues appear in a variety of South and Southeast Asian scripts. Seems that complex text layout is not being handled.

[ZeLonewolf]

Can we determine whether the noted Brahmic script ligature issues are newly introduced or an upstream issue that we need to pursue in other libraries?

Perhaps something along the lines of shieldtest could be generated for font scripts.

[ZeLonewolf]

Looks like newly introduced:

[1ec5]

Can we determine whether the noted Brahmic script ligature issues are newly introduced or an upstream issue that we need to pursue in other libraries?

This is a longstanding limitation of GL JS. The homegrown text layout engine in GL JS doesn’t have any data or logic around text shaping: maplibre/maplibre-native#778 mapbox/mapbox-gl-native#7774 mapbox/mapbox-gl-native#7528.

To the extent the OHM fontstack appears to support Indic text shaping, it’s because of a hack that relies on negative glyph metrics. This is commonplace for Khmer, but for Indic, I think it might explain why the glyphs look like 8-bit and have haphazard spacing. But even it doesn’t address the specific points in #801 (comment).

[ZeLonewolf]

Okay, so the expected script is

Therefore the old way is still wrong.

[claysmalley]

Where did you find that? The Wikidata entry for Providence spells it a different way, प्रोविडेंस.

[ZeLonewolf]

I took that screen grab off the Sanskrit Wikipedia page for Providence:
https://sa.wikipedia.org/wiki/%E0%A4%AA%E0%A5%8D%E0%A4%B0%E0%A4%BE%E0%A4%B5%E0%A4%BF%E0%A4%A1%E0%A5%87%E0%A4%A8%E0%A5%8D%E0%A4%B8%E0%A5%8D

[ZeLonewolf]

I'll pull the string direct from the database so we're doing a proper comparison.

[ZeLonewolf]

Database:

Noto Sans Devanagari:

Fontspace.com unicode inspector:

[ramSeraph]

Where did you find that? The Wikidata entry for Providence spells it a different way, प्रोविडेंस.

I think it depends on how they decided to transliterate the word.. both of them sound correct phonetically. Then again, I am not a native Hindi speaker.

[ZeLonewolf]

See: https://github.com/wipfli/maplibre-canvas-labels

[ramSeraph]

Sample code below courtesy ChatGPT.

Is this what you had in mind?

const canvas = require('canvas');
const tinySDF = require('tiny-sdf');
const fontnik = require('fontnik');
const fs = require('fs');

// Load the TTF font file using node-canvas
const font = new canvas.Font('MyFont', './MyFont.ttf');

// Set up the tiny-sdf options
const options = {
  size: 24, // size of each glyph
  buffer: 3, // amount of padding around each glyph
  radius: 8, // radius of the SDF
  cutoff: 0.25, // cutoff value for the SDF
  fontFamily: 'MyFont', // name of the font family
};

// Generate signed distance field glyphs for the font using tiny-sdf
const glyphs = tinySDF(options);

// Create a new canvas using node-canvas
const canvas = canvas.createCanvas(options.size, options.size);

// Loop through each glyph and draw it onto the canvas
for (const glyph of glyphs) {
  // Clear the canvas
  canvas.clearRect(0, 0, options.size, options.size);

  // Set the font and fill style
  canvas.font = `${options.size}px ${options.fontFamily}`;
  canvas.fillStyle = '#fff';

  // Draw the glyph onto the canvas
  canvas.fillText(glyph.char, glyph.x, glyph.y);

  // Export the canvas as a PNG image
  const buffer = canvas.toBuffer();

  // Convert the PNG image to a .pbf fontstack using fontnik
  const fontstack = fontnik.fromPng(buffer);

  // Save the .pbf fontstack file to disk
  fs.writeFileSync(`${glyph.char}.pbf`, fontstack);
}

I think you just sold me on trying chatGPT... that almost looks correct. "canvas.createCanvas" was the major glaring error I can see.

[ramSeraph]

A question for @1ec5 , would sticking to tinysdf( or equivalent ) on both server and client lead to better mixing of CJK and non CJK fonts? Which approach has more/correct information needed for label placement tinysdf or node-fontnik?

Consensus seems against merging this

[1ec5]

would sticking to tinysdf( or equivalent ) on both server and client lead to better mixing of CJK and non CJK fonts? Which approach has more/correct information needed for label placement tinysdf or node-fontnik?

In principle, both are capable of font metrics for non-complex text. TinySDF can even handle variable-width (non-CJK) glyphs as of mapbox/tiny-sdf#24, but there are still some limitations, for example mapbox/tiny-sdf#34. Mixing CJK and non-CJK is mostly a nonissue, apart from getting the baselines to match. But I’m not sure the status quo does that well, and anyways a good style would increase the text size of any CJK for legibility.

[ZeLonewolf]

I think you just sold me on trying chatGPT... that almost looks correct.

Don't get excited, supervising an AI to write code to the point of it working is actually more work than you might imagine 😆

[ZeLonewolf]

With the change in d611a08, this should solve the cross-platform issues.

From a strategic perspective, pbf font stacks are a "temporary" technology until maplibre-gl can support a more robust mechanism that can properly support ligatures etc. This is a high priority for the maplibre project: maplibre/maplibre#193

Despte the bounty, it may be some time before a change of this complexity is implemented. In the meantime, we can at least have our broken ligatured scripts at least have a nice font 😬 and work under the expectation that in the future we'll be able to directly link web fonts.

[1ec5]

To be clear, my concern about build times was limited to the overhead of downloading the crates.io index (for a single Rust dependency) and downloading the individual Noto fonts from scratch on each build. It wasn’t specifically about the node-fontnik pipeline; whatever works works, at least until GL JS has a better story around fonts.

I think we’ve solved the crates.io overhead. As for the Noto overhead, it’s only when running the build script, but not when running the start script. My suggestion below addresses that issue too.

I added some suggestions of Noto fonts that are analogous to Noto Sans Italic that we could use as a quick fix. However, Google Fonts doesn’t provide analogues in each of the writing systems we’re trying to support. We’d either need to swap in a font from a different source or synthesize an oblique font.

[1ec5]

Consider Noto Naskh Arabic as an analogue to Noto Sans Italic.

[ZeLonewolf]

I've added this font to the download, but whenever I try to use it, the script errors out with a duplicate code point error. I've verified that I don't have any overlapping ranges so I'm not sure at this point how to move it forward.

[ZeLonewolf]

The code point range at issue is within the [1536, 1791] range.

[ZeLonewolf]

I can't even run the Naskh Arabic font through the pipeline by itself. There seems to be something fundamentally wrong with this font that breaks this workflow.

[1ec5]

Hopefully we aren’t running into that classic Mapbox assumption that there’s a one-to-one correspondence between Unicode codepoints and glyph indices. We could compare this font against Noto Sans Arabic in a font editor and spot-check whether there are any discrepancies.

/ref maplibre/maplibre-native#778 (reply in thread)

[ZeLonewolf]

That does appear to be the case, though in this instance, the issue is manifesting in the fonteditor-core library.

[1ec5]

I’m pretty sure the user will never see these fonts, because GL JS is configured to use the browser’s default “sans-serif” CJK font by default: #613.

[ZeLonewolf]

I included these in order to allow a developer working on Han Unification to have multiple CJK fonts already rendered to work with. They are not bundled into any of the Americana-* fontstacks, they're each rendered out to their own fontstack.

[1ec5]

OK, these are by far the largest fonts that would be downloaded when installing the package, but I guess we can live with that as long as it only happens once.

[1ec5]

A solution regarding Han Unification should probably retain the current client-side font solution rather than switching to server-side fontstacks, which carry significant performance penalties. (Aside from wasteful bandwidth usage, it’s very easy to hog memory and overflow buffers just by looking at East Asia when using server-side CJK fontstacks.)

The client-side font infrastructure is already mostly ready for deunified CJK fonts, except that GL JS only maintains a single instance of TinySDF that it initializes as soon as it needs to render any glyphs, and TinySDF only applies fonts to the canvas once at initialization. I suspect that addressing either limitation would be trivial.

[ZeLonewolf]

If it's not useful, I can drop these fonts.

[ZeLonewolf]

I've added the additional scripts that were requested in the code reviews (this necessitated a planet rebuild with new languages added). I believe this satisfies all issues with the exception of whether to also include Han Unification fonts.

[1ec5]

Piggybacking on @jleedev’s original approval, I think we’ve since made good strides in the build system aspects of this PR, as well as the internationalization aspects. It’s good enough to ship, but let’s ticket out the various larger issues that were raised during review. For example, our support for Indic languages is not as embarrassing as before but still embarrassing – hopefully it’s enough to show promise though!

[1ec5]

Not sure if it should go here or in CONTRIBUTING.md, but we could document some editorial guidelines to aid in choosing fonts in non-Western writing systems. For example, once we get around to implementing custom CJK fonts, either on the server side via a fontstack or (preferably) on the client side via standard Web fonts, we’d want to pair Western regular sans-serif with gothic and Western regular serif with Ming, and Western italic sans-serif with regular, based on what Western and CJK texts do in analogous situations.

That said, one of the outgrowths of this PR may end up being a separate project specifically about fonts, where we’d naturally explore and elaborate on these ideas.

[ZeLonewolf]

I've captured three tail-work issues below - are there any that I might have missed?

[claysmalley]

Tracking Unicode ligatures and combining characters in #827