This topic was published by DevynCJohnson and viewed 946 times since "". The last page revision was "".
- Topics - 444
For those of you who understand the Linux GUI very well and are familiar with window managers, display servers, X11, and so forth, you may be wondering how fonts are integrated into the whole system. As we know, fonts are particular styles of text, not the text itself. For instance, the "Times New Roman" font is a popular font that will always look the same on all systems. When a user applies this font to a document, the characters will have a particular appearance. In other words, a font determines and defines the appearance of each letter, number, and other forms of characters. But how does the GUI (such as window managers and display servers) use a font file to apply the style to the letters people see on the screen.
A particular font can be added (or installed) on a system via a font file. Various font files exist in many formats and file extensions (*.ttf [TrueType], *.otf [OpenType], *.dfont, etc.). Each format has a different way of defining and drawing fonts. Some formats use a bitmap matrix (raster/bitmap fonts), mathematical formula to define the outline (vector fonts), or some other method to create and define the appearance of a font. As far as appearance is concerned, the font files only specify the shape and no other properties are defined. There is a lot to know about fonts themselves, but in this article, we are concerned with how they integrate with the GUI system.
A font-renderer reads the font file to get the rules (formulas, matrix, etc.) that provide information on how particular characters, glyphs, and symbols are to be drawn. The X11 protocol natively supports fonts in the X Logical Font Description (XLFD) format. Other font-renderers are needed to provide the ability to use other font formats. Thankfully, many font renders, font engines, or font rasterizers (which ever term you prefer) are libraries which other software can load as an extension to provide more font support. For instance, FreeType is a font renderer library that can read TrueType and OpenType font formats. However, font-renderers do not actually make the text you see on the screen. Rather, they simply read the font files and generate a gray-scale image of the character. But what is done with this raw data?
The generated gray-scale image is given to a "text layout library" (or "text layout engine"). Two popular text layout engines are Pango and Cairo. Text layout engines apply the size, color, face (like bold and italic), and other attributes to text. X11 cannot produce the various appearances of text (like color, faces, subscript, etc.) to many font formats, unlike Pango and Cairo. Even though X11 natively supports its X Logical Font Description (XLFD) font format, the text still looks simple. For other font formats, the X Server depends on text layout engines or font-renderers.
Many people think OpenGL and Mesa write and generate text, but that is not true. They are just libraries that allow programmers to use some commands in C/C++ that allow the programmer to program some graphics in their application. However, there are extensions that allow Pango and other text layout engines to create the fonts. Their real (or main purpose) is for programming the graphics in games or other applications.
XRender + XFT + FreeType
XRender is an extension to X11; X11 is a protocol used by Xorg and other display servers. XRender provides the ability to draw transparent pixels, or the alpha channel. This feature is needed for anti-aliasing (which makes the characters appear sharper) and to draw the characters themselves. As mentioned above, font-renderers produce a gray-scale image for each symbol, but yet when using text in applications, we can see the background behind the letters. The alpha-channel allows parts of the image to be transparent except for the symbol itself.
XFT (X FreeType interface library) is an interface that connects FreeType (a font renderer engine library) with XRender. Thus, XRender can extend its own abilities by using FreeType. As mentioned previously, XRender is an extension to the X11 protocol. So, with XFT, FreeType, and XRender working together, X11 has the ability to render fonts.
X Font Server
The X Font Server (xfs) provides a way for the X Server (a display server using the X11 protocol, such as Xorg) to get information from a font renderer that is running on a remote system (a font server) or the local system. Even though X11, xfs, and the font files are all on the local system, xfs communicates through TCP port 7100 and X11 uses network protocols locally. The terms "client" and "server" are still used to refer to applications (the clients) and the display server despite being local. However, many systems no longer use server-side fonts by default, unless the font-renderer is remote or an application needs to use such a font. Instead, many operating systems use client-side fonts like the XRender system. The server-side fonts are still kept (as you might see in /usr/share/fonts/X11/) because they may still be used. However, the X Server only needs xfs for remote font-renderers. The X Server is able to get local fonts itself or use the XRender extension for formats that are not natively supported by X11.
Text Layout Engines (Client-side Fonts)
Cairo and Pango are text layout engines that apply font effects and font formats that X11 cannot natively manage. The text layout engine gets the gray-scale image from a font-render and then applies the effects. Pango and Cairo are both compatible with X11 and send their output to the X Server via xlib or XCB (both of which act as a mediator/translator). Alternately, Cairo supports XFT and XRender as backends, meaning Cairo can send its generated output to XFT or XRender. Pango supports XFT as a backend. Interestingly, Cairo may have Pango manage the text instead because Pango can do so more efficiently. While Pango was designed entirely for text, Cairo is a whole vector graphics API. Keep in mind that Pango and Cairo are both just libraries that other pieces of software call. While the X Server has been running since a few moments after boot-up, Cairo and Pango only run when called or they are imported into a program that uses their abilities. Other text layout engines exist such as Graphite (http://scripts.sil.org/cms/scripts/page.php?site_id=projects&item_id=graphite_home).
Widget-Toolkits and Applications
Widget-toolkits like GTK+ and others do not create their own text. Rather, they specify the desired font, color, size, location, etc. Widget-toolkits support different text layout engines. The widget-toolkit then sends the information on the desired text it wants created to the text layout engine. Applications also have text layout engine produce the desired text. For instance, Cairo supports the PDF and Postscript formats. PDF and Postscript themselves are special computer languages for specifying how a document should look. Cairo (or some other text layout engine) reads the code and produces the PDF and PostScript documents that you read. Even the text that SVG files display are actually generated by some kind of text layout engine. The text in some terminals may be generated by the X Server using the X Logical Font Description (XLFD) fonts.
Configuration and Font Locations
Many people try to find the font configuration files which tell various pieces of software what fonts and styles to use by default. Well, the global configuration file may be found in one of the places listed below, and they are usually read by Xft. Various systems use a different name for the file, as you can see.
The local configuration file is set by the user for settings that only apply to their account.
- ~/.Xdefaults #deprecated
The font files are found in the listed places below.
After reading all this, some of you may be wondering if it is possible to not set a font (which I had said was a style for the text). In other words, can a user just use a generic or null font? The answer is no, fonts must be used, but why? Well, as far as computers are concerned, uppercase "A" is 1000001 (in binary ASCII code). Computers and software do not know what "A" should look like. Computers just see "1000001" as binary code. Even in a programming language, converting that byte sequence to a string data-type still does not produce an "A" (unless this is passed to some font renderer). The fonts declare an ASCII code (or other encoding like Unicode) and then define how the symbol should be drawn. So, there is no generic, null, or void font.