During the hype of llama.ttf months ago, I was speculating the potential of WASM shaper for even crazier purpose, one that fitter to a font shaper's duty -- to synthesize font at runtime. This project as proof-of-concept implements a synthesizer that generates and rasterizes handwriting-style font, backed by a super-lightweight RNN model (~14MiB). |
In the year 2077, when each font will run it's own virtual machine on WASM containing a "minimal" Ubuntu image, some enlightened blogger will suggest server side rendered fonts as a performance improvement.
Without trying to steal the thread, what I would care is actually the opposite direction.
Neither in Swift Playgrounds, nor in any other programming development environment apps for both mobile OSes, have I found a good development experience using pen instead of keyboard.
Given how many of us "program" in paper notebooks, it is quite incredible that besides a couple of research projects done by PhD students, no one cares to actually make it more widespread in a usable way.
In the same way that the calculator writes in the answers in your handwriting, it could write in snippets of code in your handwriting.
If it's going to be made though, it has to be e-ink. Go big or go home!
I'm on this route myself, trying various things out at https://github.com/fenollp/reMarkable-tools
Handwriting (in and out) support is very important IMO. Also being able to draw DAGs.
I'd like an e-ink device with high frame rate and HW powerful enough to run some models locally or with good enough connectivity and sensors that e.g. Computer Vision tasks can be offloaded to the users' smartphone.
Feel free to expose your ideas on there :) I welcome Open Source discussion!
as the demo video shows, it's probably not something you want to have in between you and the ability to scroll a web page or close a tab. but i guess using harfbuzz now means we're buying into a turing-complete virtual machine running an arbitrary program in order to display a glyph. how seriously crippled are the harfbuzzless rendering paths? i'm assuming opting out of harfbuzz means opting out of arabic, devanagari and other indic scripts, etc.? is there a less out-of-control alternative that doesn't leave two billion people out in the cold?
[0]: https://github.com/X-rayLaser/pytorch-handwriting-synthesis-...
We built a WebGL text renderer with full CJK support using Harfbuzz for our production whiteboard web app. I thought that was complicated until now.
As convenience, I built a Docker image that packs both the ttf file and the modified gedit together. You can try it out via `make run` as stated in the instructions.
The llama.ttf video does a pretty good job explaining what the heck is going on
I love it.
I can't wait for the next beautiful nightmare. Maybe someone should mix font rendering with PDF rendering. Of course, with a LLM doing something in the middle.
It's an experimental feature, so it's not available unless explicitly enabled during compilation.
So this is essentially native (albeit experimental) libharfbuzz. WASM is used because its how font files are scripted (when using this experimental version of lubharfbuzz)
Its important to keep in mind that wasm is a general technology and is not just used by web browsers.
https://github.com/harfbuzz/harfbuzz/blob/main/docs/wasm-sha...