Forgive my bluntness, but you appear to be far outside your depth here. Rather than fisk your comment, I'm going to try and explain the positions as I see them.
Microsoft had at least one font handling bug that exposed an arbitrary kernel privilege escalation. They closed this bug by rejecting the narrow class of malformed fonts that triggered the issue (impacting a very small number fonts people actually use). From the software engineering, security, and product perspectives it was exactly the correct solution to this particular bug, because it fixed the issue and preserved compatibility in the vast majority of cases (i.e. for valid fonts).
Now, you appear to be suggesting that instead Microsoft should have somehow altered all existing software that uses GDI font rendering to address the issue. Either that, or you're suggesting that Microsoft should break all APIs that load fonts from memory (or really any path outside of a protected system directory). So, you're either advocating the herculean task of modifying all first and third party software, while still leaving a kernel vulnerability exposed to local applications. Or, you're proposing a massive API change that would break the vast majority of applications using GDI font rendering. Either of these approaches strikes me as a very, very bad idea, and not worth seriously discussing.
Of course, the thing that makes this issue so bad is that Microsoft handles fonts in the kernel. This is a legacy issue that's obviously hurting them on the stability and security front. They're trying to move people to DirectWrite, which is far saner and safer, but it's not supported on XP. And DirectWrite won't address the local escalation issue, because there's 20+ years of software using GDI font APIs that will need to be supported for the foreseeable future. While Microsoft could certainly move GDI fonts out of the kernel, I don't see them doing so. It's a tremendous amount of work and probably not justifiable from a business perspective given that DirectWrite and GPU acceleration are really are the direction everything is headed anyway.
As for your questions about Chrome, we filter fonts using our OpenType Sanitizer (OTS), and Firefox has been using uses our code since 2011. However, fonts are very complicated, and often not entirely verifiable, because their hinting languages include a turing complete VM bytecode with variable length instructions. So, there are infinite classes of malicious behavior that you can't detect without solving the halting problem. Also, any level of user-space filtering applies to only the first stage of an exploit. Once malicious code is executing in the renderer process, it can use a font vulnerability to break out of the sandbox by executing code at kernel privilege (and the same applies to IE or any other user-space sandbox).