Very much inspired this earlier HackerNews post which put Tetris into a font, today we put an LLM and an inference engine into a font so you can chat with your font, or write stuff with your font without having to write stuff with your font.
The critical part is knowing that TTF fonts can include a virtual machine.. then he pops an llm into that and replaces instances of !!!!!! with whatever the llm outputs.
Not exactly. Harfbuzz, the font shaping library, has an optional feature to use WASM for shaping. Normal font hinting is much more restricted, precisely because Turing-complete fonts are a horrible idea.
After watching part of the video, I believe the world would benefit from a weekly television program where you could tune in each week to watch something weird, brilliant and funny. This would be a great episode #1 for that television show.
This is honestly one of my favorite channels. It is one of those things where if one asks "why" the only answer that can be given is "because."
Just look at the 4 most recent videos. Maybe start with "Harder Drive: Hard drives we didn't want or need" where he tries to make hard drives out of things that shouldn't be hard drives. This includes: by pinging the entire internet, tetris, and Covid-19 tests. But in truth the absurdity is a deep dive into the nature of how data can be stored and encoded. I think it should encourage people to pursue knowledge for the sake of knowledge and how there are frequently deep insights into seemingly dumb questions, as long as you dig deep enough.
We do these things not because they are hard, but because they are harder drives!
On his website he has an acadamic paper about red i removal. Not red eye removal. Red i. As in he superimposes a big red Comic Sans letter `i` over an image and then tries different techniques to remove it again...
While cool, technically… From a security perspective today I learned that TrueType fonts have arbitrary code execution as a ‘feature’ which seems mostly horrific.
I’m open to your idea, but can you explain in technical terms why a wasm sandbox is invulnerable to the possibility of escape vulnerabilities when other flavors of sandboxes have not been?
Certain design tools type sites like Canva or Pitch allow you to upload fonts and obviously control the content. They are frequently used by phishers to make official looking phishing pages on a trusted source, leading to a cat and mouse game where the companies try to catch phishing like indicators in the content and flag them up for human review or block immediately.
In that case being able to show arbitrary other text would definitely be a hindrance because the scanning software typically looks at the data stored in the database. However I think you don't need a Turing machine to exploit this — you could have a single ligature in a well crafted font produce a full paragraph of text.
Perhaps there's an alternative vector where someone's premade font on a site that doesn't allow font uploading can be exploited to make arbitrary calculations given certain character strings. Maybe bitcoin mining, if you could find a way to phone home with the result
If you can trick someone into installing the font, you can now control what they read. Unfortunately a lot of hacks involve the user doing something dumb and avoidable.
If this font format is successful, then given enough time, it will become legacy. People won't be as vigilant about it, and they won't understand the internals as well. This is why TIFF-based exploits became so common 20-30 years after TIFF's heyday.
It's still horrible, not in a (direct) security but in an interop sense: Now you have to embed an entire WASM engine, including proper sandboxing, just to render the font correctly. That's a huge increase of complexity and attack surface.
Normalizing the complexity doesn't make it go away.
Ideally, I'd like not to execute any kind of arbitrary code when doing something mundane as rendering a font. If that's not possible, then the code could be restricted to someting less than turing complete, e.g. formula evaluation (i.e. lambda calculus) without arbitrary recursion.
The problem is that even sandboxed code is unpredictable in terms of memory and runtime cost and can only be statically analyzed to a limited extent (halting problem and all).
Additionally, once it's there, people will bring in libraries, frameworks and sprawling dependency trees, which will further increase the computing cost and unpredictability of it.
That's why I care so much about WebAssembly (and other sandbox) features that can set a strict limit on the amount of memory and CPU that the executing code can access.
Exactly that! And speaking of quotas, nobody can explain, why Ethereum Virtual Machine-like quotas were not enforced in the standard.
Imagine that you download a .odt/docx/pdf form with embedded font in LibreOffice in 2025. You start to type some text... And font start to saturate FPU ports (i.e. div/sqrt) in specific pattern. Meanwhile some tab in browser measures CPU load or port saturation by doing some simple action, and capture every character you typed.
While neat in a "because we can" kind of sense, it really is maddening: Have we gone "compute-mad" and will end up needing a full-fledged VM to render ever-smaller subsets of UI or content until ... what?
What is the end game here?
It is kind of like a "fractal" attack surface, with increasing surface the "deeper" one looks into it. It is nightmarish from that perspective ...
> Not really, no more so than a random webpage running js/WASM in a sandbox.
... except that it can happen in non-browser contexts.
Even for browsers, it took 20+ years to arrive at a combination of ugly hacks and standard practices where developers who make no mistakes in following a million arcane rules can mostly avoid the massive day-one security problems caused by JavaScript (and its interaction with other misfeatures like cookies and various cross-site nonsense). During all of which time the "Web platform" types were beavering away giving it more access to more things.
The Worldwide Web technology stack is a pile of ill-thought-out disasters (or, for early, core architectural decisions, not-thought-out-at-all disasters), all vaguely contained with horrendous hackery. This adds to the pile.
> The only output from the WASM is to draw to screen.
Which can be used to deceive the user in all kinds of well-understood ways.
> There is no chance of a RCE, or data exfiltration.
Assuming there are no bugs in the giant mass of code that a font can now exercise.
I used to write software security standards for a living. Finding out that you could embed WASM in fonts would have created maybe two weeks of work for me, figuring out the implications and deciding what, if anything, could be done about them. Based on, I don't know, a hundred similar cases, I believe I probably would have found some practical issues. I might or might not have been able to come up with any protections that the people writing code downstream of me could (a) understand and (b) feasibly implement.
Assuming I'd found any requirements-worthy response, it probably would have meant much, much more work than that for the people who at least theoretically had to implement it, and for the people who had to check their compliance. At one company.
So somebody can make their kerning pretty in some obscure corner case.
If you think that's bad, until very recently, Windows used to parse ttf directly in the kernel, meaning that a target could look at a webpage, or read an email, and be executing arbitrary code in ring0.
Last I checked there were about 4-10 TTF bugs discovered and actively exploited per year. I think I heard those stats in 2018 or so. This has been a well known and very commonly exploited attack vector for at least 20 years.
I'm pretty sure it can't. There's nothing in a WAV file that's meant to be executed. A quick google turns up a DirectX vulnerability from 2007 (a validation error that's not inherent to the WAV format per se), and a recent case of WAV files being used to conceal malicious payloads (but coupled with a loader).
Having said that, the "arbitrary code" found in TrueType is not really arbitrary either - it's not supposed to be able to do anything except change the appearance of the font. From a security standpoint, there's no theoretical difference between a WAV and a TTF font - neither can hurt your machine if the loader is bug-free. Practically speaking though, a font renderer that needs to implement a sort of virtual machine is more complex, and therefore more likely to have exploitable bugs, than a WAV renderer that simply needs to swap a few bytes around and shove them at a DAC.
No, TTF is fully turning complete. Maybe I should have specified that in the original post. WAV is just "vibrate speaker this way" over and over again.
I realize this, but the fact that the format is "Turing complete" doesn't actually have any direct bearing on whether it's exploitable. Because the input to a TTF engine is not actually x86 machine code, it's misleading to frame it as "arbitrary code in ring0". It's not arbitrary - it can't do anything unless the TTF engine has bugs. And any format loader can have exploitable bugs, not just Turing complete ones.
Security wise, Turing completeness doesn't matter[note]. All that really matters is that the implementation of the format is complex. H264 is not Turing complete, but it is complex, and thus a frequent source of vulnerabilities. Conversely you could probably put a toy Brainfuck interpreter in ring0 and, with moderate care, be confident that no malicious Brainfuck code can take over your system.
[note] It matters a little bit if you consider it a "security" problem that you lose any guarantees of how long a file might take to load. A malicious file could infinite loop, and thus deny service. But then again, this isn't restricted to Turing complete formats - a zip bomb can also deny service this way.
(Sadly) this is nothing new. Years ago I wrangled a (modified) bug in the font rendering of Firefox [1, 2016] into an exploit (for a research paper). Short version: the Graphite2 font rendering engine in FF had/has? a stack machine that can be used to execute simple programs during font rendering. It sounded insane to me back then, but I dug into it a bit. Turns out while rendering Roman based scripts is relatively straightforward [2], there are scripts that need heavy use of ligatures etc. to reproduce correctly [3]. Using a basic scripting (heh) engine for that does make some sense.
Whether this is good or bad, I have no opinion on. It is "just" another layer of complexity and attack surface at this point. We have programmable shaders, rowhammer, speculative execution bugs, data timing side channels, kernel level BPF scripting, prompt injection and much more. Throwing WASM based font rendering into the mix is just balancing more on top of the pile. After some years in the IT security area, I think there are so many easier ways to compromise systems than these arcane approaches. Grab the data you need from a public AWS bucket or social engineer your access, far easier and cheaper.
For what it's worth, I think embedded WASM is a better idea than rolling your own eco systems for scripting capabilities.
It's technically not arbitrary. There is a stack, of sorts, but IIRC it has a depth of six or so, by default. You can do cool stuff with font shaping, but you can't easily execute arbitrary code.
This is really cool, but I'm left with a lot of questions. Why does the font always generate the same string to replace the exclamation points as he moves from gedit to gimp? Shouldn't the LLM be creating a new "inference"?
As an aside, I originally thought this was going to generate a new font "style" that matched the text. So for example, "once upon a time" would look like a storybook style font or if you wrote something computer science-related, it would look like a tech manual font. I wonder if that's possible.
So, another poster cleared up my first question. It's probably because the seed is the same. I think it would have been a better demo if it hadn't been, though.
I fail to understand how an LLM could produce two different responses from the same seed. Same seed implies all random numbers generated will be the same. So where is the source of nondeterminism?
Barring subtle incompatibilities in underlying implementations on different environments, it does, assuming all other generation settings (temperature, etc.) are held constant.
You got it, same seed in practice, but also just temperature = 0 for the demo actually. A few things I considered adding for the fun of it were 1) a way to specify a seed in the input text, 2) a way to using a symbol to say "I didn't like that token, try to generate another one", so you could do, say, "!" to generate tokens, "?" to replace the last generated token. So you would end up typing things like
"Once upon a time!!!!!!!!!!!!!!!!!!!!!!!!!!!!!SEED42!!!!!??!!!??!"
and 3) actually just allow you to override the suggestions by typing what letters on your own, to be used in future inferences. At that point it'd be a fairly generic auto-complete kind of thing.
Since it only alters the presentation of the text, not the text/data itself, maybe using a type of image-to-text tool like this could work: https://www.imagetotext.info/
PostScript files are dynamic code. You can create polygons dynamically with commands. And, of course, font FX's, styles, elipses...
Also, there's a ZMachine interpreter (text adventure player) written in PostScript which can play Zork and some libre games such as Calypso with just GhostScript, the PostScript interpreter most software use to render PostScript files.
PostScript is Turing complete and your PDF reader is a PostScript interpreter. So, yeah, potentially any PDF is instructions to a general-purpose computer.
Older versions of PDF files and readers don't know or care about what happened later. PDFs also did shady shit like being able to embed JavaScript actions and other files. They also became Turing complete when they adopted Type 4 functions in PDF 1.3 that still aren't deprecated in 2.0.
LaTeX subsumed most of the human authoring uses of PS where it was used in academia.
This is cool, as far as a practical issue though (aside from the 280gb TTF file!) is that it makes it incompatible with all other fonts; if you copy and paste your "improved" text then it will no longer say what you thought it did. It just alters the presentation, not the content. I guess you would have to ocr to get the content as you see it.
I was wondering why this was never used for an simpler autocorrect, but i guess that's why.
Also perhaps someone more educated on LLMs could tell me; this wouldn't always be consistent right? Like "once upon a time _____" wouldn't always output the same thing, yes? If so even copying and pasting in your own system using the correct font could change the content.
> if you copy and paste your "improved" text then it will no longer say what you thought it did
It's not a bug, it's a feature - a DRM. Your content can now be consumed, but cannot be copied or modified - all without external tools, as long as you embed that TTF somehow.
Which kind of reminds me of a PDF invoices I got from my electricity provider. It looked and printed perfectly fine, but used weird codepoint mapping which resulted in complete garbage when trying to copy any text from it. Fun times, especially when pasting account number to a banking app.
This is while pretty much all software that extracts structured data from PDFs throws away the text and just OCRs the page. Too many tricks with layouts and fonts.
I'm always surprised how "generate PDF from Word" turns one word into 10 different print points, all with just a single letter.
Or even straight lines in a table. The straight lines from a table boundary get hacked into pieces. You'd think one line would be the ideal presentation for a line, but who are you to judge PDF?
Apple provides OCR through VisionKit ImageAnalyzer API – https://developer.apple.com/documentation/visionkit/imageana... – albeit that is only officially supported to call from Swift (although apparently you can expose it to Objective C if your write a "proxy Swift framework"–a custom Swift framework that wraps the original and adds @objc everywhere–I assume such a proxy framework could be autogenerated using reflection, but I'm not sure if anyone has written a tool that actually does that). There is also the older VNRecognizeTextRequest API which is supported by Objective C, but its OCR quality is inferior.
A very similar thing is also just built in to the screenshot tool, at least in Windows 11, easier for me to use since it's the same keybind as always to take a screenshot, then it's just a tool in it.
> The font shaping engine Harfbuzz, used in applications such as Firefox and Chrome, comes with a Wasm shaper allowing arbitrary code to be used to "shape" text.
Has there already been a proposal to add scripting functionality to Unicode itself? Seems to me we're not very far from that anymore...
Considering the actual complexity of rendering e.g. Urdu in decent, native-looking way you presumably do want some Turing-complete capabilities at least in some cases, cf "One handwritten Urdu newspaper, The Musalman, is still published daily in Chennai.[232] InPage, a widely used desktop publishing tool for Urdu, has over 20,000 ligatures in its Nastaʿliq computer fonts." (https://en.wikipedia.org/wiki/Urdu#Writing_system)
Edit—the OP uses this exact use case, Urdu typesetting, to justify WASM in Harfbuzz (video around 6:00); seems like Urdu has really become the posterchild for typographic complexity these days
> The font shaping engine Harfbuzz, used in applications such as Firefox and Chrome, comes with a Wasm shaper allowing arbitrary code to be used to "shape" text.
In that case could you ship a live demo of this that's a web page with the font embedded in the page as a web font, such that Chrome and Firefox users can try it out without installing anything else?
> Usage: Just download llama.ttf (60 MB download, since it's based on the 15M parameter TinyStories-based model demoed above) and use it like you would any other font.
It seems like it'd be possible to, instead of typing multiple exclamation points, have one trigger-character (eg. ). And then replace that character visually with an entire paragraph of text, assuming there aren't limits to the width of a character in fonts. I suppose the cursor and text wrapping would go wonky, though.
You could also use this to make animated fonts. An excuse to hook up a diffusion model next?
> The font shaping engine Harfbuzz, used in applications such as Firefox and Chrome, comes with a Wasm shaper allowing arbitrary code to be used to "shape" text.
Oh, this can't be used for nefarious purposes. What could POSSIBLY go wrong?!
The author categorizes this as "pointless" but some things I can think of is being able to create automated workflows within an app that didn't previously allow it or had limited scope and then creating app interoperability with other app's using the same method.
I may be doing this wrong but...the font provided just install as OpenSans and does not provide any functionality at least in mousepad or LibreOffice Writer. I am talking about the 90mb one
Yeah, sorry, that could have been clearer, I added a few more instructions. Basically, chances are that even if you've got Harfbuzz running, you're still running a version with no Wasm runtime. If so, chances are you can get away with building it with Wasm support, then add the built library to LD_PRELOAD before running the editor.
That was useful. I have indeed compiled and installed wasm-micro and now meson build it successfully. Tho "meson compile -C build" returns an error about not finding "hb-wasm-api-list.hh". Do you have any experience of that?
EDIT: Nevermind. Using the exact commits you linked give another error (undefined reference to wasm_externref_ref2obj). I give up
>build Harfbuzz with -Dwasm=enabled and build wasm-micro-runtime, then add the resulting shared libraries, libharfbuzz.so.0.60811.0 and libiwasm.so to the LD_PRELOAD environment variable before running a Harfbuzz-based application such as gedit or GIMP
It'd be lovely if someone embedded the font in a website form to save us all the trouble of demoing it
It would not be of much use as no browser enables this experimental feature. So unless you somehow build a wasm build of Harfbuzz with the feature enabled and embed it on there nothing will happen.
Are there _any_ generally available consumer applications (document viewers, printers, obscure browsers, ...) that use a TTF font renderer with the WASM feature enabled?
According to demo, this feature has no opt-in, so if Android/iOS/any Linux distro ships with "better fonts feature for LibreOffice" it will be enabled in every text editor/browser/electron app, up to systemd blue screen of death.
161 comments
[ 3.0 ms ] story [ 173 ms ] threadhttps://news.ycombinator.com/item?id=40737961
Just look at the 4 most recent videos. Maybe start with "Harder Drive: Hard drives we didn't want or need" where he tries to make hard drives out of things that shouldn't be hard drives. This includes: by pinging the entire internet, tetris, and Covid-19 tests. But in truth the absurdity is a deep dive into the nature of how data can be stored and encoded. I think it should encourage people to pursue knowledge for the sake of knowledge and how there are frequently deep insights into seemingly dumb questions, as long as you dig deep enough.
https://www.adultswim.com/videos/off-the-air
or on Youtube https://www.youtube.com/playlist?list=PLQl8zBB7bPvLWfGCVicg_...
The only output from the WASM is to draw to screen. There is no chance of a RCE, or data exfiltration.
In that case being able to show arbitrary other text would definitely be a hindrance because the scanning software typically looks at the data stored in the database. However I think you don't need a Turing machine to exploit this — you could have a single ligature in a well crafted font produce a full paragraph of text.
Perhaps there's an alternative vector where someone's premade font on a site that doesn't allow font uploading can be exploited to make arbitrary calculations given certain character strings. Maybe bitcoin mining, if you could find a way to phone home with the result
If this font format is successful, then given enough time, it will become legacy. People won't be as vigilant about it, and they won't understand the internals as well. This is why TIFF-based exploits became so common 20-30 years after TIFF's heyday.
There's very little code in the world that I wouldn't want to run in a robust sandbox. Low level OS components that manage that sandbox is about it.
Ideally, I'd like not to execute any kind of arbitrary code when doing something mundane as rendering a font. If that's not possible, then the code could be restricted to someting less than turing complete, e.g. formula evaluation (i.e. lambda calculus) without arbitrary recursion.
The problem is that even sandboxed code is unpredictable in terms of memory and runtime cost and can only be statically analyzed to a limited extent (halting problem and all).
Additionally, once it's there, people will bring in libraries, frameworks and sprawling dependency trees, which will further increase the computing cost and unpredictability of it.
Imagine that you download a .odt/docx/pdf form with embedded font in LibreOffice in 2025. You start to type some text... And font start to saturate FPU ports (i.e. div/sqrt) in specific pattern. Meanwhile some tab in browser measures CPU load or port saturation by doing some simple action, and capture every character you typed.
iirc browsers fuzz the precise timing of calls for exactly this reason already?
[1] https://www.destroyallsoftware.com/talks/the-birth-and-death...
What is the end game here?
It is kind of like a "fractal" attack surface, with increasing surface the "deeper" one looks into it. It is nightmarish from that perspective ...
... except that it can happen in non-browser contexts.
Even for browsers, it took 20+ years to arrive at a combination of ugly hacks and standard practices where developers who make no mistakes in following a million arcane rules can mostly avoid the massive day-one security problems caused by JavaScript (and its interaction with other misfeatures like cookies and various cross-site nonsense). During all of which time the "Web platform" types were beavering away giving it more access to more things.
The Worldwide Web technology stack is a pile of ill-thought-out disasters (or, for early, core architectural decisions, not-thought-out-at-all disasters), all vaguely contained with horrendous hackery. This adds to the pile.
> The only output from the WASM is to draw to screen.
Which can be used to deceive the user in all kinds of well-understood ways.
> There is no chance of a RCE, or data exfiltration.
Assuming there are no bugs in the giant mass of code that a font can now exercise.
I used to write software security standards for a living. Finding out that you could embed WASM in fonts would have created maybe two weeks of work for me, figuring out the implications and deciding what, if anything, could be done about them. Based on, I don't know, a hundred similar cases, I believe I probably would have found some practical issues. I might or might not have been able to come up with any protections that the people writing code downstream of me could (a) understand and (b) feasibly implement.
Assuming I'd found any requirements-worthy response, it probably would have meant much, much more work than that for the people who at least theoretically had to implement it, and for the people who had to check their compliance. At one company.
So somebody can make their kerning pretty in some obscure corner case.
Last I checked there were about 4-10 TTF bugs discovered and actively exploited per year. I think I heard those stats in 2018 or so. This has been a well known and very commonly exploited attack vector for at least 20 years.
Having said that, the "arbitrary code" found in TrueType is not really arbitrary either - it's not supposed to be able to do anything except change the appearance of the font. From a security standpoint, there's no theoretical difference between a WAV and a TTF font - neither can hurt your machine if the loader is bug-free. Practically speaking though, a font renderer that needs to implement a sort of virtual machine is more complex, and therefore more likely to have exploitable bugs, than a WAV renderer that simply needs to swap a few bytes around and shove them at a DAC.
Security wise, Turing completeness doesn't matter[note]. All that really matters is that the implementation of the format is complex. H264 is not Turing complete, but it is complex, and thus a frequent source of vulnerabilities. Conversely you could probably put a toy Brainfuck interpreter in ring0 and, with moderate care, be confident that no malicious Brainfuck code can take over your system.
[note] It matters a little bit if you consider it a "security" problem that you lose any guarantees of how long a file might take to load. A malicious file could infinite loop, and thus deny service. But then again, this isn't restricted to Turing complete formats - a zip bomb can also deny service this way.
Whether this is good or bad, I have no opinion on. It is "just" another layer of complexity and attack surface at this point. We have programmable shaders, rowhammer, speculative execution bugs, data timing side channels, kernel level BPF scripting, prompt injection and much more. Throwing WASM based font rendering into the mix is just balancing more on top of the pile. After some years in the IT security area, I think there are so many easier ways to compromise systems than these arcane approaches. Grab the data you need from a public AWS bucket or social engineer your access, far easier and cheaper.
For what it's worth, I think embedded WASM is a better idea than rolling your own eco systems for scripting capabilities.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1248876
[2] I know, there are so many edge cases. I put this in the same do not touch bucket as time and names.
[3] https://scripts.sil.org/cms/scripts/page.php?id=cmplxrndexam...
As an aside, I originally thought this was going to generate a new font "style" that matched the text. So for example, "once upon a time" would look like a storybook style font or if you wrote something computer science-related, it would look like a tech manual font. I wonder if that's possible.
But that's due to the possibility model configuration changes on the service end and not relevant here.
"Once upon a time!!!!!!!!!!!!!!!!!!!!!!!!!!!!!SEED42!!!!!??!!!??!"
and 3) actually just allow you to override the suggestions by typing what letters on your own, to be used in future inferences. At that point it'd be a fairly generic auto-complete kind of thing.
I guess that’s the closest you get to copying.
Also, there's a ZMachine interpreter (text adventure player) written in PostScript which can play Zork and some libre games such as Calypso with just GhostScript, the PostScript interpreter most software use to render PostScript files.
LaTeX subsumed most of the human authoring uses of PS where it was used in academia.
I was wondering why this was never used for an simpler autocorrect, but i guess that's why.
Also perhaps someone more educated on LLMs could tell me; this wouldn't always be consistent right? Like "once upon a time _____" wouldn't always output the same thing, yes? If so even copying and pasting in your own system using the correct font could change the content.
It's not a bug, it's a feature - a DRM. Your content can now be consumed, but cannot be copied or modified - all without external tools, as long as you embed that TTF somehow.
Which kind of reminds me of a PDF invoices I got from my electricity provider. It looked and printed perfectly fine, but used weird codepoint mapping which resulted in complete garbage when trying to copy any text from it. Fun times, especially when pasting account number to a banking app.
Or even straight lines in a table. The straight lines from a table boundary get hacked into pieces. You'd think one line would be the ideal presentation for a line, but who are you to judge PDF?
Which is open source (MIT-licensed), the source code is here: https://github.com/microsoft/PowerToys/tree/main/src/modules...
It is written in C#, and uses the Windows.Media.Ocr UWP API to do the actual OCR part: https://learn.microsoft.com/en-us/uwp/api/windows.media.ocr?... – so if your app runs on Windows it can potentially call the same API and get OCR for free
Apple provides OCR through VisionKit ImageAnalyzer API – https://developer.apple.com/documentation/visionkit/imageana... – albeit that is only officially supported to call from Swift (although apparently you can expose it to Objective C if your write a "proxy Swift framework"–a custom Swift framework that wraps the original and adds @objc everywhere–I assume such a proxy framework could be autogenerated using reflection, but I'm not sure if anyone has written a tool that actually does that). There is also the older VNRecognizeTextRequest API which is supported by Objective C, but its OCR quality is inferior.
I'm not sure what the best answer for Linux or Android is. I guess https://github.com/tesseract-ocr/tesseract ?
The 280GB you saw is the Llama3-70B model which is basically chatgpt level (if not better).
Would be cool if you could turn up/down the LLM’s temperature by pressing different keys other than just !!!!
Say pressing keyword numbers 0-9
Has there already been a proposal to add scripting functionality to Unicode itself? Seems to me we're not very far from that anymore...
Edit—the OP uses this exact use case, Urdu typesetting, to justify WASM in Harfbuzz (video around 6:00); seems like Urdu has really become the posterchild for typographic complexity these days
Maybe you meant adding it to OpenType?
In that case could you ship a live demo of this that's a web page with the font embedded in the page as a web font, such that Chrome and Firefox users can try it out without installing anything else?
> Usage: Just download llama.ttf (60 MB download, since it's based on the 15M parameter TinyStories-based model demoed above) and use it like you would any other font.
https://huggingface.co/nickypro/tinyllama-15M/tree/main
You could also use this to make animated fonts. An excuse to hook up a diffusion model next?
But things like this might be possible (for now): https://gwern.net/dropcap
Oh, this can't be used for nefarious purposes. What could POSSIBLY go wrong?!
The post isn't even about image-generating AI.
EDIT: Nevermind. Using the exact commits you linked give another error (undefined reference to wasm_externref_ref2obj). I give up
It'd be lovely if someone embedded the font in a website form to save us all the trouble of demoing it