Most current work on screen rendering for fonts concentrates on client side fonts, because:
The shaping process for complex text languages requires access to all the tables of the font. So, shaping on the client side with fonts on the server side involves huge amounts of network traffic.
You can try to solve this by putting the shaping on the server (like STSF), but then you run into the problem that text measurement (one of the most speed sensitive operations for GUI apps) involves round trips to the server. And editing becomes much more complex because editing needs access to details of the shaping implementation.
Server side fonts inherently make WYSIWYG much more difficult. How do I match rendering between the printer and the screen if my X print server and my X display server have different sets of fonts?
Using built-in printer fonts was common in older operating systems, but is almost never done these days; built-in printer fonts seldom provide a satisfactory user experience.
Is using client side fonts possible within the Xprint model? Well, in theory, certainly. You could figure out some way to incrementally download glyphs from all interesting font formats and then reconstruct them to embed in the output on the server. But the client, protocol, and server complexity is high. Downloading non-subsetted fonts is prohibitively expensive for asian languages.
The core X11 rendering model is archaic and does not compare to current expectations of application developers and users; new extensions to replace it like RENDER are too low-level and pixel-oriented to be useful for printing.
The Xprint FAQ tries to rebut this problem saying that the X11 rendering model is good enough for "about 95%" of applications. But what about the remaining 5%? What if I want to draw a smooth bezier curve? What if I want to draw a gradient? According to the FAQ, such applications should generate postscript fragments.
One of the core premises of the argument for Xprint is that generating PDL in the application is wrong. If applications with even slightly sophisticated rendering needs have to generate PDL anyways, then how is this advantage an advantage?
And as better rendering becomes available for the screen, that 5% of applications is going to become a larger fraction.
Another possibility raised is that a better rendering API could be adding to X or that OpenGL could be used; this is certainly true. But it's not at all obvious that OpenGL is a suitable printer API ... for example, how do you know the right tesellation limits if you don't know the output resolution? And a new 2D X extension, or implementation of OpenGL that targets arbitrary printers certainly would be a big task.
Xprint advocates make a big point about how Xprint is network transparent and "designed for the enterprise."
But there is already a de-facto standard for enterprise printing -- IPP -- this is used on Windows, OS X, Unix, Linux.
Real corporate environments are heterogeous. Few people are going to want to use remote Xprint servers to do network printing.
Whether or not Xprint could have been developed into a full-fledged solution for Linux, the actual state is that other technological roads have been taken, and all the purported advantages of Xprint have been solved in other ways or are being solved in other ways.
The ability to query printer capabilities:
This is solved by using IPP to talk to print servers and printers. The state of the art for Linux printing is no longer dumping postscript to lpr; applications can easily get the status and capabilities of the printer the user has selected.
A consistent rendering API between the screen and the printer:
This has been provided at the application level for a long time at the toolkit layer by Qt, Java AWT, etc.
Cairo is showing promise as a next generation technology that can be used across multiple different toolkits.
Internationalization:
While the combination of Xprint and STSF potentially offers poweful complex-text capabilities on the server side, equivalent capabilities provided by client side toolkits like Pango and Qt are already deployed.
Authentication:
IPP authentication to print servers via Kerberos, while still under development for CUPS and Linux, is a commonly deployed technology that fits in well with enterprise infrastructures.
On the other hand, it's not clear how the client-to-client authentatication schemes used for X authentication (and MIT-MAGIC-COOKIE and ssh forwarding are all that is commonly used) would work when printing to remote printers.