Pour voir la différence, le plus simple est de relancer le système: cela n'oblige pas à mémoriser  les commandes spécifiques à la prise en compte des nouvelles polices.
La premier constat que l'on fait, est la rapidité du lancement de KDE et de toute application: seul le répertoire spécifié est scruté à la recherche des polices à lisser et non plus l'ensemble des répertoires de polices. Tout est lissé, même le simple texte dans Kedit, ou l'affichage en héxadécimal dans Khexedit.
En revanche, KWrite ne fonctionne plus. Le terminal Kvt est incapable d'afficher correctement les caractères semi-graphiques de Midnight Commander. Pour ce faire, on lui préfèrera le terminal Rxvt (Figure 4)

Le progrès le plus frappant, outre celui visible dans Konqueror ou Krusader, est celui touchant Quanta+. Le montage ci-desous montre le même document prévisualisé avec lissage, en noir, et sans lissage, en rouge dans Quanta+. Tout commentaire serait superflu (Figure 5)
 
 

De plus, on constate que sans cette manipulation, KWord et les autres composants de KOffice, offraient dans leur menu déroulant la possibilité d'utiliser n'importe quelle police reconnue par XFree. En réalité, bon nombre d'entre elles ne s'affichaient pas, et lorsqu'elles le faisaient, c'était avec le même aspect baveux que Quanta+.: parfois, on obtenait purement et simplement  la fermeture de l'application avec la fameuse fenêtre "Gestionnaire de crash de KDE"  et le message type: "L'application... s'est terminée anormalement et a provoqué le signal 11 (SIGSEGV)".
Après installation des polices comme indiqué ci-avant et demande de lissage dans XftConfig, KOffice  permet de choisir uniquement parmis les nouvelles polices, à l'exclusion de toute autre. Et elles sont alors parfaitement utilisables et lissées: c'était le but recherché.

Tant qu'on y est, pourquoi ne pas faire bénéficier AbiWord, l'autre traitement de texte de Linux "compatible" Word, du même traitement? C'est facile et permet d'économiser pas mal de place sur le disque dur. En effet, AbiWord arrive avec ses propres polices qui sont des doublons de ce qui existe déjà sur le système. Les polices en question se trouvent dans: /usr/ share/abisuite/AbiSuite/fonts (chemin de la Mandrake 8). Il s'agit de 4 Mo de fichiers afm et pfa. Or, rappelons-nous que Kfontinst conserve les TTF d'origine et ajoute les conversions en afm et pfb qu'il opère. Donc AbiWord, qui utilise des Type1, pourra utiliser les mêmes polices que KWord -et donc les véritables Times, Arial et Courrier- converties en Type1 par Kfontinst.

On opérera ainsi:
-copier  dans ~/.kde/share/fonts/ TrueType les quatre fichiers *.u2g  d'AbiWord définissant la forme des caractères (glyph) génériques Adobe ainsi que ceux des Dingbats et des Symbol (A noter qu'AbiWord fonctionne et affiche les caractères de nos TTF converties même sans cette précaution; cependant, si ça ne fait pas de bien, ça ne peut pas faire de mal non plus! Quelqu'un plus au fait de l'utilité de ces quatre fichiers pourrait-il en informer l'aimable société? )
-ignorer le fichier fonts.scale.abi dont l'objectif est de donner des pseudonymes décents -Arial, Times New Roman,..- à des polices plus ou moins ressemblantes.
-effacer (ou renommer si l'on a des doutes) le fichier /usr/share/abisuite/AbiSuite/fonts
-créer un lien symbolique (avec MC: facile!) /usr/share/abisuite/AbiSuite/fonts pointant sur ~/.kde/share/fonts/TrueType. Cette opération a pour but d'indiquer à AbiWord quelles polices il doit utiliser,  tout en le bernant, puisqu'on lui fait croire que son répertoire .../fonts est toujours présent, tandis qu'en réalité on le dirige subepticement vers notre répertoire. Les ruses de Linux, c'est incroyable! Mais vrai.

L'image suivante montre AbiWord affichant les nouvelles polices (Figure 6): évidemment, c'est du Gtk, donc pas de lissage (en juillet 2001).

Resterait à se pencher sur le cas douloureux de Star Office, dont l'afffichage lamentable déshonore considérablement ses immenses qualités. Ce ne sera pas pour aujourd'hui. Un volontaire peut s'y atteler s'il le désire.