Description of Problem: There is a widely dispersed truetype font, which is broken completely. "mtsorts.ttf" is the main baddy out there, and is listed in Microsoft knowledgebase as being totally broken and causing problems. All code in the distribution which opens up truetype fonts should be modified to detect this font by checking the md5sum and comparing it with a known md5sum of the bad font. Sometime in the future, I'll track down a copy of this font, and md5sum it. We can then blacklist it.
Why do we need to do this? If a font is broken, FreeType will catch that, and we have to handle other broken fonts as well....
Because in the past, I've received bug reports from users unable to get X to start up after they installed new ttf fonts. On several occasions of debugging it turned out a font named mtsorts.ttf was to blame. Removing that font made everything work again. Someone pointed out to me a Microsoft Knowledgebase article which claims that there is a buggy mtsorts.ttf font in the wild which will cause MS WIndows to crash/freak out. Same thing happens in Linux. I don't have a copy of this font, but I will obtain one sometime. Since it is not an uncommon font, and not uncommon problem, I think we should ensure that this font does not crash xfs, X, or anything else, and preferably a warning/error is logged or somesuch so users know they've got a bogus/bad font. Doesn't solve the problem, but does work around it and prevent users from having a bad experience, and us from getting bogon bug reports of this nature. I just figured an md5sum would be a good way to hone in on the bad font. The filename check isn't good enough, as a later version of the font fixes the bug.
This should be done in the font handling library, by not freaking on invalid data. Be tolerant in what you accept, etc...
Created attachment 71608 [details] mtsorts.ttf
I was one of the people that suffered from this! It was segfaulting the xftcache program. I have an old copy of the mtsorts.ttf file, which is included as an attachement.
Well, if the problem is "xftcache segfaults when fed mtsorts.ttf" the answer isn't "blacklist mtsorts.ttf" but "fix xftcache" ! (xftcache is gone now, btw, replace with fc-cache)
Owen, that's exactly the point of this tracker bug. To make sure all applications/whatever that read font files do not crash when reading fonts. How that happens can be a variety of ways. What's more important is that apps don't crash, and users don't get oddball behaviour due to bad fonts being present. There are a few ways this can be accomplished. Any method is fine with me. It's not a high priority in any case. I just wanted to track it in bugzilla for myself, to play around with it at some point in the future. If any specific app/lib crashes with bad font input such as the mtsorts.ttf, then another bug report should be filed against that app/lib to be fixed, and possibly tracked against this one too.
Yu, can you verify that ttmkfdir does'nt die with this problem font, and fix ttmkfdir if it does have a problem with it? TIA
These problems no longer appear to be reported, so I'm closing this.