search

glyphr-studio / Glyphr-Studio-2

Glyphr Studio v1 is more than a decade old. V2 is here to save the day.
https://www.glyphrstudio.com/v2
109 stars 13 forks source link

Investigate using TTX to load/save #193

Closed mattlag closed 2 months ago

mattlag commented 5 months ago
Castux commented 3 months ago

There is also https://github.com/caryll/otfcc which is pure C and might be easier to compile to WASM. I can look into that :)

mattlag commented 2 months ago

Any investigation is very welcome, @Castux ! I started a small investigation into web-alchemy's node.js fonttools port. It's been working pretty well, though it depends on a Node environment. I'm also trying out React, Typescript and Electron for the first time, so the overall project may be kind of rough... but the small step of using some sort of ttx in a js environment

https://github.com/mattlag/visual-ttx

In the grand scheme of things, at the moment we're using OpenType.js to read / write OTF files. They do not have 100% table support. The only reason I think this investigation would be interesting is if it enabled some big new areas for us, namely:

Switching off OpenType.js would be a very major feature, but if we're able to do the things on this list, it would be worth it. Some port of TTX seems like it has potential.

Castux commented 2 months ago

So I've ported and wrapped the relevant code from otfcc into a WASM compilable library:

https://github.com/Castux/otfcc/tree/load-from-memory

You can check my notes there on the README. Basically, it should work, but does not, and I haven't gotten further than that. Getting an out-of-bounds access for an input file that works perfectly fine natively. It's quite frustrating :) I'll try and dig a bit more but the debugging options for WASM are quite limited.

Castux commented 2 months ago

Unfortunately, I am hitting a roadblock there. Impossible to debug that issue. Out of sheer curiosity, I compiled the whole program/library using the Zig compiler, which acts as a drop-in C compiler. And the native binary crashes with the same input fonts. So I am suspecting that the source uses non-standard compiler features, or abuses preprocessors tricks in a way that doesn't port safely (and fails somehow with the emscripten or Zig compilers).

At this point I'm thinking it's easier to just add the needed features to OpenType.js

mattlag commented 2 months ago

Thank you for the investigation. I was poking around OpenType.js pull requests and it actually looks like they have color fonts and variable fonts being added soon. So, I think you can drop this investigation.

Thank you for looking into it, though! It was well outside of my skill set.

I'm going to close this because OpenType.js actually looks like a contender.