Ping. It would be useful to get an idea of what would be involved in making this work, and whether there are any on-wiki workarounds or fixes that could be made.

Aren't the UniversalLanguageSelector webfonts exporting?

@Billinghurst no, they don't export because they're not part of the page itself, they're sucked in on-wiki via CSS. So the exporter would need to:

• Notice they are used
• Acquire the fonts in question
• Bundle the font into the export file somewhere
• Update references to the old ULS/font CDN/whatever URL to point to the bundled font

Remember that your average e-reader will not be able to just go and fetch the font down off the web like a browser (usually) can.

I've created T294509: Include webfonts specified in CSS, but I'm not sure that'll fix things for how ULS loads fonts: we can't just look for a @font-face definition with a src: url(…) (can we?). So maybe the fix is to look for font names in CSS (e.g. style="font-family:UnifrakturMaguntia, UnifrakturCook,Unifraktur…) and bundle them into the epub if they're installed locally.

For Blackletter it looks like that'd be UnifrakturMaguntia from http://unifraktur.sourceforge.net/maguntia.html (which I can't find in a Debian package, but might not be looking correctly).

Actually, sorry, I might be complicating things... how does ULS serve fonts? For instance, when I view a page with {{blackletter}}, Firefox dev tools shows UnifrakturMaguntia as the active font, but doesn't show any webfont file being downloaded (and I don't have that font installed locally).