4 ms·

I'll try a summary: WASM shaper is part of Harfbuzz, a text shaping engine for font rendering. It allows embedding WASM code in the font for influencing the way

I'll try a summary: WASM shaper is part of Harfbuzz, a text shaping engine for font rendering. It allows embedding WASM code in the font for influencing the way text is rendered into glyphs. > The WASM code inside a font is expected to export a function called shape which takes five int32 arguments and returns an int32 status value. > ..The general goal of WASM shaping involves receiving and manipulating a buffer contents structure, which is an array of infos and positions (as defined below). Initially this buffer will represent an input string in Unicode codepoints. By the end of your shape function, it should represent a set of glyph IDs and their positions.

bradrn 3y ago
Note also: > Specifically, Harfbuzz is purely responsible for shaping; although Harfbuzz does have APIs for accessing glyph outlines, typically other libraries in the free software text rendering stack are responsible for text segmentation into runs, outline scaling and rasterizing, setting text on lines, and so on. > Harfbuzz is therefore restricted to turning a buffer of codepoints for a segmented run of the same script, language, font, and variation settings, into glyphs and positioning them. This is also all that you can do with the WASM shaper; you can influence the process of mapping a string of characters into an array of glyphs, you can determine how those glyphs are positioned and their advance widths, but you cannot manipulate outlines, variations, line breaks, or affect text layout between texts of different font, variation, language, script or OpenType feature selection.
slimsag 3y ago
Font rendering is incredibly complex, perhaps one of the most complex things in computer software. It already required execution of a virtual machine: > TrueType systems include a virtual machine that executes programs inside the font, processing the "hints" of the glyphs, in TrueType called “instructions”. These distort the control points which define the outline, with the intention that the rasterizer produce fewer undesirable features on the glyph. Now it just _also_ requires potential execution of arbitrary WASM code, too.
- tadfisher 3y ago
  There have been numerous CVEs in various text-rendering engines for just this reason, and that's because TTF was invented before it became common to render arbitrary fonts downloaded from the Internet. A new format with a well-defined WASM interface would be a welcome development; bonus points for a TTF-to-$newFormat conversion tool.
- cmyr 3y ago
  Hinting might be a red herring here: these font formats are unsafe almost by design, since they consistently rely on a pattern of reading a value out of a chunk of memory and then treating that value as a pointer offset where additional values are read. The proposed WASM shaping implementation would be a replacement for traditional OpenType layout[1] which is already turing complete[2]), and in this sense using WASM is significantly safer than the alternative. Your comment suggests that "execution of arbitrary WASM code" is something that we should be scared of, but the entire point of WASM is that it allows for safe/isolated compilation of arbitrary code. [1] https://simoncozens.github.io/fonts-and-layout/features.html https://simoncozens.github.io/fonts-and-layout/features.html [2] https://litherum.blogspot.com/2019/03/addition-font.html https://litherum.blogspot.com/2019/03/addition-font.html
  - slimsag 3y ago
    I did not suggest "execution of arbitrary WASM code" is something that we should be scared of - I stated the facts, and you inferred something I did not write. > The proposed WASM shaping implementation would be a replacement for traditional OpenType layout It's not a proposal AFAIK, it's already implemented today in the harfbuzz codebase. I also do not think it is a 'replacement' for the traditional system, I doubt anyone will disable the ability to render the entire ecosystem of fonts out there which have not been updated to use WASM - so it seems likely it's just another point of complexity added to font rendering in general.
pdpi 3y ago
Perhaps counterintuitively, this is exactly the sort of usecase WASM is meant for. A VM that needs to be simultaneously lightweight/cheap and very high performance (because it's being used to do the heavy lifting for a slower/heavier runtime), but is still expected to run untrusted code and is therefore thoroughly sandboxed.

bradrn 3y ago

Note also: > Specifically, Harfbuzz is purely responsible for shaping; although Harfbuzz does have APIs for accessing glyph outlines, typically other libraries in the free software text rendering stack are responsible for text segmentation into runs, outline scaling and rasterizing, setting text on lines, and so on. > Harfbuzz is therefore restricted to turning a buffer of codepoints for a segmented run of the same script, language, font, and variation settings, into glyphs and positioning them. This is also all that you can do with the WASM shaper; you can influence the process of mapping a string of characters into an array of glyphs, you can determine how those glyphs are positioned and their advance widths, but you cannot manipulate outlines, variations, line breaks, or affect text layout between texts of different font, variation, language, script or OpenType feature selection.

slimsag 3y ago

Font rendering is incredibly complex, perhaps one of the most complex things in computer software. It already required execution of a virtual machine: > TrueType systems include a virtual machine that executes programs inside the font, processing the "hints" of the glyphs, in TrueType called “instructions”. These distort the control points which define the outline, with the intention that the rasterizer produce fewer undesirable features on the glyph. Now it just _also_ requires potential execution of arbitrary WASM code, too.

tadfisher 3y ago
There have been numerous CVEs in various text-rendering engines for just this reason, and that's because TTF was invented before it became common to render arbitrary fonts downloaded from the Internet. A new format with a well-defined WASM interface would be a welcome development; bonus points for a TTF-to-$newFormat conversion tool.
cmyr 3y ago
Hinting might be a red herring here: these font formats are unsafe almost by design, since they consistently rely on a pattern of reading a value out of a chunk of memory and then treating that value as a pointer offset where additional values are read. The proposed WASM shaping implementation would be a replacement for traditional OpenType layout[1] which is already turing complete[2]), and in this sense using WASM is significantly safer than the alternative. Your comment suggests that "execution of arbitrary WASM code" is something that we should be scared of, but the entire point of WASM is that it allows for safe/isolated compilation of arbitrary code. [1] https://simoncozens.github.io/fonts-and-layout/features.html https://simoncozens.github.io/fonts-and-layout/features.html [2] https://litherum.blogspot.com/2019/03/addition-font.html https://litherum.blogspot.com/2019/03/addition-font.html
- slimsag 3y ago
  I did not suggest "execution of arbitrary WASM code" is something that we should be scared of - I stated the facts, and you inferred something I did not write. > The proposed WASM shaping implementation would be a replacement for traditional OpenType layout It's not a proposal AFAIK, it's already implemented today in the harfbuzz codebase. I also do not think it is a 'replacement' for the traditional system, I doubt anyone will disable the ability to render the entire ecosystem of fonts out there which have not been updated to use WASM - so it seems likely it's just another point of complexity added to font rendering in general.

pdpi 3y ago

Perhaps counterintuitively, this is exactly the sort of usecase WASM is meant for. A VM that needs to be simultaneously lightweight/cheap and very high performance (because it's being used to do the heavy lifting for a slower/heavier runtime), but is still expected to run untrusted code and is therefore thoroughly sandboxed.