6 ms·
This is a lovely write up, but oh boy... when I see: > Finally, I proposed that the future of font shaping and drawing/ painting will involve a fully-programma
by wokwokwok 2y ago
This is a lovely write up, but oh boy... when I see:
> Finally, I proposed that the future of font shaping and drawing/ painting will involve a fully-programmable paradigm.
> Two tongue-in-cheek mis-uses of the HarfBuzz Wasm shaper appeared recently: the Bad Apple font, and llama.ttf. Check them out!
See... the thing about solving problems is that, eventually you realize that any kind of problem can be solved by simply making a platform that can execute arbitrary code.
...and you see it again and again.
Declarative compile definition in make? Why not just make it code and use cmake?
Declarative infra in terraform? Why not just make it code and use pulumi?
Declarative ui? Why not just make it code and use javascript?
Database that holds data? Why not just use stored procedures and do it in code?
The list just goes on and on, and every time you have to roll back to a few important questions:
- Is the domain so complicated you really need arbitrary code execution?
- Are you inventing a new programming language for it?
- How will people program and test for the target?
- How will you manage the security sandbox around it?
It's just such a persuasive idea; can't figure out how to deal with the complexity in configuration? Make it code and push the problem to the user instead!
Sometimes it makes sense. Sometimes it works out.
To be fair, I get it, yes, font layouts are harder than they look, and yes, using WASM as a target solves some of those issues, but I look at llama.ttf and I really have to pause and go...
...really? Does my font need to be able to implement a LLM?
I don't really think it does.
...and even if the problem is really so complex that rendering glyphs requires arbitrary code (I'm not convinced, but I can see the argument), I think you should be doing this in shaders, which already exist, already have a security sandbox and already have an ecosystem of tooling around it.
I think inventing a new programmable font thing is basically inventing a new less functional form of shaders, and it's a decision that everyone involved will come to regret...
- moonchild 2y agoprogrammable hinting was already a thing. it's just switching to wasm from a bespoke language
- wokwokwok 2y agoIt's still just doing exactly what shaders do, which is crazy. Explain to me exactly why, other than 'I guess someone already implemented some kind of basic version of it' that you would have to have custom CPU code rendering glyphs instead of a shader rendering SDF's like literally everyone does with shaders already? It's not a good solution. It's a bad, easy solution. We have a solution for running arbitrary GPU accelerated graphics instructions; it has a cross platform version with webGPU. This font thing... looks a lot like 'not invented here' syndrome to me, as an uninvolved spectator. Why would you chose or want not to use GPU acceleration to render your glyphs? What 'arbitrary code' does a font need to do that couldn't be implemented in a shader? Maybe the horse has already bolted, yes, I understand programmable fonts already exist.. but geez, its incomprehensible to me, at least from what I can see.
- behdad 2y agoHi. As mentioned, I'll expand on my motivations in a future paper. -behdad
- adrian_b 2y agoWhile this presentation is extremely interesting, it would have been far more useful if you would have exported this view into a downloadable PDF file, instead of giving access to just this ephemeral preview.
- bsder 2y ago> CPU code rendering glyphs instead of a shader rendering SDF's 1) Because SDFs suck badly (and don't cover the whole field) when you want to render sharp text. SDFs are fine when used in a game where everything is mapped to textures and is in motion at weird angles. SDFs are not fine in a static document which is rendered precisely in 2D. 2) Because GPUs handle "conditional" anything like crap. GPUs can apply a zillion computations as long as those computations apply to everything. The moment you want some of those computations to only apply to these things GPUs fall over in a heap. Every "if" statement wipes out half your throughput. 3) Because "text rendering" is multiple problems all smashed together. Text rendering is vector graphics--taking outlines and rendering them to a pixmap. Text rendering is shaping--taking text and a font and generating outlines. Text rendering is interactive--taking text and putting a selection or caret on it. None of these things parallelize well except maybe vector rendering.
- forrestthewoods 2y agoI don't disagree. But I have kind of the opposite take. I can't count how many times I've seen simple code get turned into a hideously complex declarative language that has serious gaps. Simple UI library code? Turn it into a custom declarative syntax that is now limited! Simple build system that works and is debuggable? Turn it into a declarative syntax that can't be debugged and can't handle all the edge cases! And so on and so forth. I will admit that the idea of a font programming language sounds genuinely awful to me. So I don't really disagree with your premise. But I'm increasingly annoyed with declarative system when vanilla code is often simpler, more flexible, and more powerful (by necessity). :)
- nineteen999 2y agoWhat else are we supposed to do with all these massively multicore CPU's and gigabytes of RAM?
- funcDropShadow 2y agoYou are missing the point. Finally, it'll be possible to exploit side-channel attacks without using Javascript in the browser. Static HTML+CSS+Fonts websites won't be safe anymore. Yippieee! Finally, there is no reason to allow disabling Javascript anymore. And you could add backdoors to hacked fonts that are activated by magic spells. Isn't it great.