As mentioned in KaTeX/KaTeX#614 (comment), there may be room for improvement in the way our fonts are created. The font creation currently uses mftrace, which apparently renders the fonts to bitmaps and then converts these back into vector fonts. This feels like a really strange approach, considering that the metafont input is already in vector form. A better alternative might be md2pt1. Quoting its description:

mf2pt1 fa­cil­i­tates pro­duc­ing PostScript Type 1 fonts from a METAFONT source file. It is not, as the name may im­ply, an au­to­matic con­verter of ar­bi­trary METAFONT fonts to Type 1 for­mat. mf2pt1 im­poses a num­ber of re­stric­tions on the METAFONT in­put. If these re­stric­tions are met, mf2pt1 will pro­duce valid Type 1 out­put with more ac­cu­rate con­trol points than can be re­verse-en­gi­neered by TeXtrace, mf­trace, and other pro­grams which con­vert bitmaps to out­line fonts.

I'm not sure what exactly these constraints are, and to what degree computer modern (or one of its more unicode-complete drop-in replacements) satisfies them. I ran the script and got a bunch of warnings, so it may not be as easy as I would have hoped at first. I found that lilypond switched from mftrace to mf2pt1 in 2008, so perhaps we can learn a bit from them about how to solve problems that pop up. They seem to be dealing with different fonts, though. And as far as I can tell, they are no longer using the mf2pt1 command line tool, but only some of its machinery.

I also had a look at what the program actually does. It uses metapost (which supports syntax quite similar to metafont) to generate one EPS file per glyph in the encoding vector. You can see these if you comment out all unlink calls in mf2pt1. These EPS files are then parsed and turned into something fontforge will understand. I would assume that the blackening we use for our fonts should be possible with metapost, too. It might again require hacking the perl script to adapt the corresponding command invocation.

But we could also consider doing something else, and going from EPS straight to ttx from the fonttools package. In that case, we have to deal with the problem that the EPS files will usually contain commands that produce cubic Bézier curves, while traditionally TTF only supports quadratic curves. One solution would be not to use TTF but to use OTF which supports cubic splines in its CFF/Type 2 form. The same holds for WOFF, as far as I understand. Not sure all supported browsers can handle this, though. So we might be better off approximating the cubic curve by a quadratic one. fontello/svg2ttf#25 might offer some help on how to do this in the context of fonts. Or we use CFF as input to fontforge, and let that recode things to classic TTF since it has support to do so, too. Come to think of it, we could look at the code for that as well, since it appears to have a sufficiently liberal license.