The X font server (xfs) provides a standard mechanism for an X server to communicate with a font renderer, frequently one running on a remote machine. It usually runs on TCP port 7100 or thereabouts.

Current Status

The use of server-side fonts is currently considered deprecated in favour of client-side fonts ^[1] Such fonts are rendered by the client, not by the server, with the support of the Xft2 or cairo libraries and the XRender extension.

Besides, for the few cases in which server-side fonts are still needed, the new servers have its own integrated font renderer, so that no external one is needed. Server-side fonts can be configured now in the X server configuration files. For example /etc/X11/xorg.conf will set the server-side fonts for Xorg.

All these facts have made font servers obsolete.

No specification on client-side fonts is given in the core protocol. In will have to be send after rendering.

Future

As of October 2006, the manpage for xfs on Debian states that:

FUTURE DIRECTIONS

Significant further development of xfs is unlikely. One of the original motivations behind it was the single-threaded nature of the X server ? a user?s X session could seem to ?freeze up? while the X server took a moment to rasterize a font. This problem with the X server, which remains single-threaded in all popular implementations to this day, has been mitigated on two fronts: machines have gotten much faster, and client-side font rendering (particularly via the Xft library) is the norm in contemporary software..

Performance

User experience show the same performance on both X server+direct font serving and X server+font server path.

Deployment Issues

So the choice between local filesystem font access and xfs-based font access is purely a local deployment choice. It does not make much sense in a single computer scenario.

References

1. ↑ Matthieu Herrb and Matthias Hopf. New Evolutions in the X Window System.

See also

• X Window core protocol