Well, that's the thing. Web fonts are hard. PDF fonts are super hard. Both at once is...actually maybe not hideous these days. Oh, I would not wish the task of devising such an algorithm, but the subset of vector fonts supported in PDF and that in browsers aren't totally disjoint, I think.

Modern processors can handle the relevant conversion math without really waking from sleep, which will no doubt make it more frustrating when some W3C third party resource security model WG fistfight from 2013 makes it impossible to both construct and use a webfont on the client. (There may be some hideous blob URL magic, but those are length constrained so you could up in N subset nonce fonts bucketing M custom glyphs from the source document, with a hideously complex fifty-case rewrite for all the p90 ways of mapping fonts in PDF (or is that 90 cases and p50?) to render the document in the editor. And then have to handle the actual editing cases, like what happens when your subset nonce font of a subset embedded font doesn't map any character to the keycode you just saw, and you want to try to give the user something with metrics sorta matching what they wanted instead of Helvetica or Times New Roman out of a naïvely constructed fontset.

I may have worked with PDF in browsers one time too many, before. But the idea of using WASM to smuggle real tools into this impoverished environment actually makes a lot of sense to me...