Is it really necessary to support so many different font formats?
I get a big webpack build because of this:

You may say this is not a problem, because they are not loaded in the webpage. In my specific case, it actually is, because I'm inlining the js and css (including the font) in my html file in production. Because, of some limitations of the web app I'm working with. I need to upload a single html file. So, when I inline everything with webpack, every font is embedded the html as a base64 string. Which is a lot of redundant bloat.
This is may be a rare case, but I still wondering. Why not just use woff and woff2? This will break IE8, but I think many libs don't support IE8 anymore. Even jquery.
@kasperpeulen We'd like to support people who need KaTeX in IE 8, which is why we provide the fonts. If you don't want to support it, you can modify static/fonts.less and set @use-eot and @use-ttf to false and make a build using those settings.
@kevinbarabash Maybe we should make .woff the default now, and let people enabled .eot and .ttf if they really want it? That would probably make sense for the majority of people.
@xymostech that sounds reasonable.
@kasperpeulen depending on your application, you may not need each of the different font files either. Some of them are only used for particular styles, e.g. \mathfrak.
I suggest embedding fonts into CSS with base64 encoding and split it into different CSS files of that given font type (ttf/woff/eot)...
(http://sosweetcreative.com/2613/font-face-and-base64-data-uri)
Pros:
Cons:
Many formulas will only require some of the fonts, so I'd rather not inline all of them into the CSS.
No longer supporting IE8 by default sounds like it would break the contract. After all, the README claims support for IE8 at the moment. So I'd say such a change should bump the version number to 0.7.0 at least. Personally I don't think some obscure corner cases warrant breaking existing setups. Sure, being able to customize the build to only use recent font formats would be nice, but in my opinion the default packaged version of KaTeX should continue to support IE8 until there is a better reason not to.
@gagern never said all of them. It's up to a discussion.
We'd like to support people who need KaTeX in IE 8, which is why we provide the fonts. If you don't want to support it, you can modify static/fonts.less and set @use-eot and @use-ttf to false and make a build using those settings.
I have done that, thanks. Not ideal though, as I need to check in this build now in the repo (including all the fonts) and I may have to update this manually in the future. (Alternatively I could fork katex and publish that on npm, but also not ideal).
Personally I would vote for not supporting IE8. Not just for my reason, but because IE8 is an unsupported browser, it doesn't get security updates anymore. It is dangerous to be on IE8. If you are on Vista you can (and should) upgrade to IE9. If you are on Window 7+, only IE11 is supported.
Maybe we should make .woff the default now, and let people enabled .eot and .ttf if they really want it? That would probably make sense for the majority of people.
I vote for this. Set @use-eot and @use-ttf to false by default, then people can set @use-eot to true if they need to support IE8.
Just wondering, as a kind of middle ground, would it make sense to ship the WOFF versions in the bundle, but use absolute URLs referencing a suitable public copy of these fonts for EOT and TTF? Not sure how much pain we'd have with CORS in such a setup, but it _might_ be better than not having the older formats available at all.
Is now a good time to take ttf and eot fonts out of the master branch? KaTeX doesn't run in IE8 and and that fact is now acknowledged in README.
I think we'll still want the ttf files though since we generate the other files from ttf. Also, Android support for ttf is better than for woff/woff2.
@kasperpeulen what's your webpack setup? Is there no way to control which fonts get included in in your bundle?
We've removed eot fonts from the katex package. I believe the original problem could be solved by changing the webpack config to extract the font files from the bundle. I think ExtractTextPlugin might do the trick. If the fonts are separate files then the browser can decide which version of the font makes the most sense for it to download.