"But what about computing font glyphs in userland THEN"
Too many ring switches, I'm afraid. For example antialiasing needs to know what's behind the glyph (which may not be known by the application, if not under its control). Fonts antialising may use "hints" inside the font data to avoid they look the wrong way.
Also, font rendering may be hardware accelerated as well. With the increased size of display devices, and their resolution, even displaying 2D objects had to be accelerated. Windows old GDI is often too slow for some tasks, and that's why hardware accelerated Direct2D was introduced.
Still, you can rasterize fonts in user space and sent the result to the kernel for display, AFAIK there are some libraries that do that - but it's simpler when you can pre-render a whole static output (i.e. a PDF page) than when you need to manipulate a dynamic output.
It is true that maybe the new wave of flat, solid color designs may not need it, but remember Windows 7 enabled the "aero" interface only if the underlying hardware was good enough, and some effects could be disabled if there's not enough power.
Biting the hand that feeds IT
