Download/traduzioni/FontsInteractXServer/index-old
...making Linux just a little more fun!
Come i Font Interagiscono con X Server e X Client
By Thomas Adam
[ The following is taken from a reply the author sent to TAG in response to a question about fonts. Some of the answers in TAG are so good that they simply deserve to be made into articles. :) -- Ben ]
Introduzione
Dietro la grafica, c'e' una chiara mole di cose che accadono quando un applicazione richiede l'uso di un font. A causa delle installazioni di default che incluono entrambi il server X e i loro rispettivi client sulla stessa macchina, molte delle funzionalita' sono mascherate. Comunque, il server X gioca un ruolo principale nella gestione dei font memorizzati sotto di esso.
Ci sono due meccanismi diversi che lavorano, per quanto riguarda i font: uno fa uso di un server dei font, l'altro no.
I Fonts e la loro collocazione
Prendendo un tipico sistema che non usa un server dei font, le definizioni dei font
sono una proprieta' del server X; che, esso conosce e tiene traccia di quali
font c'e' sul proprio sistema. I default di X11 per la ricerca dei font sono in
/usr/lib/X11/fonts/*
.
Tipicamente, una definizione standard da /etc/X11/XF86Config-4 (e dal nuovo xorg.conf) i file possono essere simili a:
Section "Files" FontPath "unix/:7100" # local font server # if the local font server has problems, we can fall back on these FontPath "/usr/lib/X11/fonts/misc" FontPath "/usr/lib/X11/fonts/cyrillic" FontPath "/usr/lib/X11/fonts/75dpi/" FontPath "/usr/lib/X11/fonts/100dpi/" FontPath "/usr/X11R6/lib/X11/fonts/sgi" FontPath "/usr/lib/X11/fonts/Type1" FontPath "/usr/lib/X11/fonts/CID" FontPath "/usr/lib/X11/fonts/100dpi:unscaled" FontPath "/usr/lib/X11/fonts/75dpi:unscaled"
Un'applicazione puo' richiedere un font per la visualizzazione, e
il server X lo cerchera' cortesemente nelle directory indicate
memorizzate (in molte, come nell'esempio sopra). Il comando
'
xset q
'
elenchera' quell'informazione
[1]
, e addirittura dei path di font
possono essere aggunti con'
xset +fp /some/location/
'.
Comunque, quello non fa niente di piu' che aggiungere una definizione di directory.
Per fare in modo che il server X sia consapevole del fatto che e' stata aggiunta una nuova locazione,
occorre fare un refresh con
'
xset fp rehash
'.
Descrizioni del font
Esiste un comodo meccanismo nei font di X11, che consiste negli alias dei nomi dei font. Se ignoriamo per il momento i font TrueType, il comando 'xlsfonts' lista i font cosi':
-adobe-avant garde gothic-book-o-normal--0-0-0-0-p-0-iso8859-1 -adobe-courier-bold-o-normal--17-120-100-100-m-100-iso10646-1 ... [ Tolte molte altre linee ]
Prendiamone una per esempio — ecco il significato di ogni singola parte:
Figure 1: Struttura di un font tipico.
Ci sono molte informazioni, vero? Bene, si, e' vero, ma ci sono molte informazioni utili . Approssimativamente (e fuori dalla mia testa ) ecco il significato di ogni singola parte:
- Foundry (fabbrica) riferisce la ditta che produceil font (in questo caso Adobe).
- Family (famiglia) riferisce il tipo di font.
- Weight (dimensione) e' la visualizzazione del font (il quale include anche "normal").
- I vari pixel e point si riferiscono alla dimensione del font rispetto alla risoluzione del font visualizzato (la quale e': orizzontale o verticale.)
- Spacing (spaziatura) si riferisce al fatto che il font sia mono-spazio (m) or proporzionale (p).
Autto questo puo' essere seccante e noioso, e certamente sarebbe un incubo se si dovesse ricordare tutte le informazioni insieme. Ecco dove aliasing e wildcarding diventano utili.
La maggior parte delle applicazioni X11 che usano il database X11 Resource Database (XRDB) permettono a varie risorse di essere impostate con un appropriato font. Esempio:
*xterm.font: *courier-bold-o-*-120*
Questo dovrebbe essere in un modo carino auto-esplicante, giusto? E' analogo allo spesso utilizzato a riga di comando [2] di:
<program> -fn '*courier-bold-o-*-120*'
Il server X poi cerca quel font, espandendo il wildcard come deve essere. Questo e' lasciato largo spazio all'utente per assicurare che il corretto posizionamento di qualsiasi wildcard ia curato, dal momento che in molte occasioni non si accoppiera' o trovera' font non intenionali. Il server X attraversera' qualsiasi percorso nel suo fontpath, nell'ordine in cui le directory sono elencate , fino a che non si accoppia con un font. Non si puo' sollecitare l'ordine a sufficenza — e' analogo al modo in cui viene cercato un file eseguibile, nella $PATH. Il primo font trovato e' comunque dentro la lista dei fontpaths, sebbene due o piu' font si accoppiassero con la wildcard.
Aliasing e' leggermente differente, cioe' piutosco che l'utente tenga conto dell'accoppiamento su wildcard, un file "font.alias" contiene nomi brevi per i font (nomi alternativi, se si vuole). Eccone uno:
lucidasans-bolditalic-8 -b&h-lucida-bold-i-normal-sans-11-80-100-100-p-69-iso885 9-1
Essenzialmente, e' un file a due colonne, con il nokme alternativo nella prima colonna, e il nome del font reale nella seconda. Coe prima, se si usa un alias per caricare un font, il server X lo cerchera' nelle directory dei font di turno. Questo ha in piu' il beneficio di essere in grado di specificare gli alias per font che sono in altre directory.
Un file fonts.alias e' associato anche con un file fonts.dir. Si puo' pensare questo file come un database massivo che usa il server X. E' un po' come font.alias, eccetto che questo file elenca i seguenti:
Actual Font Name Font Name
Qaundo si chiede al server X di ricercare un font, it will look in fonts.dir to ascertain the font based on either the long name, or the alias (since the alias is mapped before the fonts.dir is looked in.) If you've ever used the mkfontdir(1) command, this is what it does — creates font.dir files in each and every fontpath listed.
Font Servers
Now onto font servers: You don't need them. Really — unless you're in some large multinational corporation that has hundreds of workstations connecting to an X server with different vendors. In the R5 release of X11, they were used for uniformity, to ensure that font names remained consistent, so that applications could load fonts, thus sharing them. What happens is something like the following:
Figure 2: How XFS interacts with the X server and X client(s)
The machine "Server" has a number of services running on it -- including the XFS (X Font Server). The local X server running on a client is hence told to use a font server (which is typical of the line):
FontPath "unix/:7100"
The font server responds by supplying the X server on the client with a list of font names applications (X clients) can load and display on the screen. (Under the hood there's a lot which goes on, but I'll skip that.) Note the "role reversal" here [3] : the X server is the client with respect to the font server — hence it is itself a "font client" — other examples include a printer, which would also talk to the font server, where necessary (although not shown in the above diagram).
Old versions of Red Hat used to insist on running a TrueType font server, for no other reason than presumably to annoy everyone.
[1] Programatically, this can be achieved via the XSetFontPath() call.
[2] Note the hard quotation marks here, so as not to perform globbing at the shell.
[3] Rick Moen comments: Unix newcomers are often confused by the notion of applications being X11 clients and the graphical display being driven by a server process, which somehow is opposite to people's expectations. They think: surely the applications are serving up display data, thus making them servers, which the graphical display is receiving, thus making it a client. However, what's being served up, to both local applications and remote ones via X11 network access, is the graphical display software's drawing services, as a central system facility for all applications that need it. Thus the applications are, for that purpose, clients.
Talkback: Discuss this article with The Answer Gang
I used to write the long-running series "The Linux Weekend Mechanic", which was started by John Fisk (the founder of Linux Gazette) in 1996 and continued until 1998. Articles in that format have been intermittent, but might still continue in the future. I currently write occasional articles for LG, whilst doing a few things behind the scenes for it. I'm also a member of The Answer Gang.
I was born in Hammersmith (London UK) in 1983. When I was 13, I moved to the sleepy, thatched-roofed, village of East Chaldon in the county of Dorset. It is very near the coast, and Lulworth Cove, which is where I used to work. Since then I have moved to Southampton, and currently attend University there, studying for a degree in Software Engineering.
I first got interested in Linux in 1996 having seen a review of it in a magazine (Slackware 2.0). I was fed up with the instability that the then-new operating system Win95 had and so I decided to give it a go. Slackware 2.0 was great. I have been a massive Linux enthusiast ever since. I ended up with running SuSE on both my desktop and laptop computers. Although I now use Debian as my primary operating system.
I am actively involved with the FVWM project, writing documentation, providing user-support, writing ad-hoc and somewhat esoteric patches for it.
Other hobbies include reading. I especially enjoy reading plays (Henrik Ibsen, Chekhov, George Bernard Shaw), and I also enjoy literature (Edgar Allan Poe, Charles Dickens, Jane Austen to name but a few).
I am also a keen musician. I play the piano in my spare time.
Some would consider me an arctophile (teddy bear collector).
I listen to a variety of music .