Wasm-shaper info

[asibahi]

Initial attempt at reading the Wasm table that's embedded by the harfbuzz tool. I tried on one of their example and it seems to load the wasm file just fine, tho I have not tried running it yet as it requires functions exports and whatnot and i am still reading about them.

I took the liberty to add a feature flag, tho I am not quite sure if I am doing it right.

[notgull]

It may be worth it to add a way to actually parse the WASM, even at a basic level. It seems fairly simple (probably less complicated than some of the tables already parsed by this crate), see here.

[asibahi]

I figured it should have the same treatment as svgs and raster images where you simply provide the data and let the caller worry about it. As the caller still actually needs to pull in the wasm dependency to run it.

Also the functions exported to the module depend on shaper functionality.

Edit: here is the calling code from the wasmer crate: https://github.com/wasmerio/wasmer/blob/main/examples/exports_function.rs

[asibahi]

I have been giving this some thought throughout the day. Here is a list of the function that are currently expected by the wasm module. (Found in the harfbuzz-wasm crate conveniently at the start of the file.

    fn face_get_upem(face: u32) -> u32;
    fn font_get_face(font: u32) -> u32;
    fn font_get_glyph(font: u32, unicode: u32, uvs: u32) -> u32;
    fn font_get_scale(font: u32, x_scale: *mut i32, y_scale: *mut i32);
    fn font_get_glyph_extents(font: u32, glyph: u32, extents: *mut CGlyphExtents) -> bool;
    fn font_glyph_to_string(font: u32, glyph: u32, str: *const u8, len: u32);
    fn font_get_glyph_h_advance(font: u32, glyph: u32) -> i32;
    fn font_get_glyph_v_advance(font: u32, glyph: u32) -> i32;
    fn font_copy_glyph_outline(font: u32, glyph: u32, outline: *mut CGlyphOutline) -> bool;
    fn face_copy_table(font: u32, tag: u32, blob: *mut Blob) -> bool;
    fn buffer_copy_contents(buffer: u32, cbuffer: *mut CBufferContents) -> bool;
    fn buffer_set_contents(buffer: u32, cbuffer: &CBufferContents) -> bool;
    fn debugprint(s: *const u8);
    fn shape_with(
        font: u32,
        buffer: u32,
        features: u32,
        num_features: u32,
        shaper: *const u8,
    ) -> i32;

And the module should export one function called shape: (from here)

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. Three of the five arguments are tokens which can be passed to the API functions exported to your WASM code by the host shaping engine:

• A shape plan token, which can largely be ignored.
• A font token.
• A buffer token.
• A feature array.
• The number of features.

If the wasm handling were to be done in ttf-parser, some of these functions do make sense in it. The rest could maybe done through callbacks or closures of some sort.

I plan to play with it (in a private crate) a bit over the week see what I can understand out of all of this.

[RazrFalcon]

So the Wasm table is just a blob? It has no structure? I cannot find a spec.
And if so, there is no need to patch ttf-parser at all. Just call face.raw_face().table(Tag::from_bytes(b"Wasm")). Job's done.

If the wasm handling were to be done in ttf-parser, some of these functions do make sense in it.

Most definitely not. ttf-parser is a parser. If you plan to execute WASM code - you have to do this on the caller side, i.e. rustybuzz.

[notgull]

Yes, but WASM isn't just raw bytes, as mentioned above. It can be parsed. So wouldn't it be ttf-parser's responsibility to parse the WASM?

[RazrFalcon]

So wouldn't it be ttf-parser's responsibility to parse the WASM?

Yes. This is way out of scope.

And why ttf-parser should be parsing it to begin with? Aren't we should simply pass it to a WASM VM? Maybe I'm missing the point of this table?

[asibahi]

So the Wasm table is just a blob?

Yes. It is pretty much a .wasm blob that's expected to export certain API and has access to other API, and passed to a WASM runtime to .. run.

And if so, there is no need to patch ttf-parser at all. Just call face.raw_face().table(Tag::from_bytes(b"Wasm")).

Hah. I did not know that was possible. This simplifies things considerably then.

I guess this way of doing thins could stand to be made clear in documentation.

Most definitely not. ttf-parser is a parser. If you plan to execute WASM code - you have to do this on the caller side, i.e. rustybuzz.

Yeah I thought as much, that's why I opted to just pass the blob.

==

In light of the table function you mentioned , perhaps there is no real point to this PR, since the work to implement the WASM shaper can all happen on rustybuzz's side.

[RazrFalcon]

Let's see how rustybuzz integration will go. Maybe we would have to modify ttf-parser eventually.

[asibahi]

This can probably be closed now.