lowMemory option causes glyphs to be skipped when writing font (with toArrayBuffer)

[Balearica]

Overview

The lowMemory option appears to save memory by only loading the most commonly-used glyphs initially, and then loading other glyphs on an as-needed basis. However, when writing fonts using toArrayBuffer, it appears that any unloaded glyphs are excluded from the font file, rather than being loaded as needed. This can be confirmed by attempting to download the font in the demo site (which uses lowMemory mode) by running the following from the console.

const fontArrayBuffer = font.toArrayBuffer();
const blob = new Blob([fontArrayBuffer], { type: 'font/otf' });
const link = document.createElement('a');
link.href = URL.createObjectURL(blob);
link.download = 'font.otf';
document.body.appendChild(link);
link.click();
document.body.removeChild(link);

The resulting font is missing the vast majority of the glyphs. Forcing an unloaded glyph to be loaded (e.g. ~ can be loaded into memory by running font.charToGlyph('~')) results in it being included in the download. While the resulting font will open, in addition to being missing glyphs, FontForge often throws errors because tables may reference glyphs that no longer exist.

Possible Solutions

While it would be nice to have font writing work as expected in lowMemory mode, I don't think that is necessary. The primary reason this behavior is problematic is that it is not error-evident. Running toArrayBuffer after enabling lowMemory will run without any error, and produces a font that is just correct enough to work within a basic development example or automated test. Therefore, alerting the developer with a warning message when toArrayBuffer is called and lowMemory is enabled would resolve the primary issue.

Your Environment

• Version used: e9c090e
• Font used:
• Browser Name and version:
• Operating System and version (desktop or mobile):
• Link to your project: