Font media files

[appgurueu]

Problem

Allow font media files for games/mods/packs to customize fonts.

Solutions

Add fonts to the media loading & sending process.

Additional context

I am probably going to open a PR.

[rubenwardy]

I support this

[sorcerykid]

If this capability is added, then it would be nice if an API could be devised to utilize a variety of fonts for different UI components. This includes setting the default font for chat, for the HUD, for tooltips, and for formspecs (individual elements could also be stylized beyond the default, of course),

The hypertext[] formspec element in particular needs be carefully considered, as it's in need of a more robust and future-proof methodology for stylizing text if multiple font options become available. Right now the font attribute only accepts "normal" and "mono". Instead, this should specify the actual font-family name. Although the former keywords could be retained for backward compatibility, of course.

[appgurueu]

If this capability is added, then it would be nice if an API could be devised to utilize a variety of fonts for different UI components. This includes setting the default font for chat, for the HUD, for tooltips, and for formspecs (individual elements could also be stylized beyond the default, of course),

The hypertext[] formspec element in particular needs be carefully considered, as it's in need of a more robust and future-proof methodology for stylizing text if multiple font options become available. Right now the font attribute only accepts "normal" and "mono". Instead, this should specify the actual font-family name. Although the former keywords could be retained for backward compatibility, of course.

I was thinking of allowing rich strings not only with color & translation support, but also with font support: "\27f(fontname.ttf)Text in font"

[v-rob]

With a new GUI/HUD system where all things like chat are actual GUI/HUD elements, setting the font of them would be as simple as setting their style field. As for hypertext, there's no problem with normal and mono; after all, doesn't CSS have sans, sans-serif, and monospace as fallbacks? Regardless, hypertext is marked as experimental because it has a lot more potential problems than just that, so backwards compatibility is not essential.

As for embedding fonts (and other formatting information) in strings, I personally don't like that. It's too easy for it to go wrong (see vertlabel for instance; it breaks escape codes by inserting newlines) and it's not a robust solution. HTML is better in this regard since it has real nesting of elements, which is much better than a hard-coded solution in the engine. I would vouch for a real solution like that (perhaps with a word-wrap layout container).

I do support the concept of font media files.

[jeremyshannon]

We were just discussing this on #Exile, this would be a great thing to have. Our fonts looking like an office application is lame.

Currently it is technically possible to set a font (for singleplayer at least) by altering minetest settings, but it's hacky and global, so you have to unset it before the player exits. If the system crashes, the system-wide font will be replaced with the game font. So it's not really worth doing without some kind of proper font system.

[erlehmann]

Note that if fonts are sent from the server to the client this can introduce security vulnerabilities, as detailed here: https://googleprojectzero.blogspot.com/2015/07/one-font-vulnerability-to-rule-them-all.html

I would consider it a good idea to limit the computational power of the font formats allowed as much as possible, so that they can be easily be parsed and verified.

[jeremyshannon]

Looks like it affects Postscript type 1 and Opentype fonts on 32 bit platforms? Truetype doesn't include the PS type 1 functions that include the vulnerability.

[rubenwardy]

How do browsers protect against malicious fonts?

[erlehmann]

Looks like it affects Postscript type 1 and Opentype fonts on 32 bit platforms? Truetype doesn't include the PS type 1 functions that include the vulnerability.

@jeremyshannon I guess that is the kind of thinking that will help to limit the attack surface. So given that you seem to know a bit about this, what is a safe font format subset in your opinion and how can a program validate that a font file adherse to the restrictions?

How do browsers protect against malicious fonts?

@rubenwardy I have no idea what they do beyond “sandboxing”. Given issues like the above mentioned one or https://security-tracker.debian.org/tracker/CVE-2020-15999 I have my doubts that they do much validation before throwing the font to the renderer.

Just to clarify my understanding: In this proposed feature the font would be sent unencrypted, i.e. an attacker could intercept and modify it even?

[jeremyshannon]

My knowledge comes mostly from reading the article you linked on googleprojectzero above, and a bit from having been around when these formats were new and there was a lot of discussion about implementing them in gnu/linux. I'm not a font rendering expert or anything.

The vulnerability you linked just now is fixed in freetype as of october 2020, according to the links there. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972586#29

For the more recent one, it sounds like just disallowing otf and psf fonts (and ensuring that the ttf font really is a ttf font) should be sufficient for the time being, as that older format doesn't support the postscript-style structures that are vulnerable.

[appgurueu]

How do browsers protect against malicious fonts?

Browsers use a different font format called WOFF (Web Open Font Format). It seems WOFF is more complex than TTF though, but we might be able to just lift whatever library browsers use for WOFF loading.

[rollerozxa]

Browsers use a different font format called WOFF (Web Open Font Format). It seems WOFF is more complex than TTF though, but we might be able to just lift whatever library browsers use for WOFF loading.

Keep in mind TTF (and OTF) is still supported in browsers, just not recommended since WOFF(2) offers smaller filesizes due to compression.

[erlehmann]

The vulnerability you linked just now is fixed in freetype as of october 2020, according to the links there. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972586#29

I understand that vulnerabilities get fixed.

What I want though is making entire classes of bugs impossible by making smart (i.e. restrictive) choices about font formats.