Polices de caractères Unix et AbiWord

La manière que AbiWord gère les polices de caractères dans l'environnement Unix comporte ses particularités et est une source de confusion, difficultés et de frustration parmi les utilisateurs d'AbiWord. Les développeurs d'AbiWord planifient de reprendre la conception du mécanisme de gestion des polices, mais c'est une tâche qui est loin d'être triviale, elle sera abordée après la version 1.0. Entre temps, ce document brosse les grandes lignes des aspects principaux de la gestion des polices dans AbiWord, c'est la raison de ce document et fournit des instructions détaillées au sujet de la personnalisation des polices.

Exigences de polices de caractères d'AbiWord

L'utilisation des polices par AbiWord découle de deux séries de limitations : les besoins d'un traitement de texte WYSIWYG et la nature même de la gestion des polices dans l'environnement Unix/X. (NdT : WYSIWYG vient de l'anglais "What You See Is What You Get" et signifie que l'information visible à l'écran apparaîtra tel quel lors de l'impression.)

Polices de caractères dans l'environnement Unix/X

Pour des raisons historiques les applications Unix affichent leurs données à l'écran et la transmettent pour impression de manières totalement différentes. L'écran est accédé par l'entremise du système d'affichage X qui fournit une abstraction de haut niveau pour la gestion des polices de caractères. X permet à l'application, l'utilisation de polices de types variés sans nécessiter la connaissance des détails. L'affichage du texte à l'écran s'en trouve simplifié, mais rencontre certains inconvénients, comme nous verrons dans un moment.

Par contraste, à l'impression l'application traduit le document en langage de programmation PostScript et transmet le programme PostScript à l'imprimante (ou à un interpréteur PostScript qui le traduit dans un code que l'imprimante peut comprendre). Même si le langage PostScript est extrêmement puissant, sa gestion des polices est totalement différente de celle du système X. A la base, chaque police que le document requière doit être intégrée dans la représentation PostScript du document, ce qui implique que la police doit être dans un format que le langage PostScript comprend. De plus, puisque le langage PostScript est conçu pour produire des documents imprimés de haute qualité, il fonctionne à beaucoup plus haute résolution qu'à l'écran. Pour être en mesure de produire la disposition pour sortie PostScript, l'application doit être en mesure de retrouver les dimensions de chacun des caractères directement de la police (ou plus précisément, du fichier de métrique qui lui est associé) ; il ne peut pas seulement mettre à l'échelle les dimensions obtenues du serveur X pour affichage à l'écran puisqu'il en résulterait des erreurs d'arrondis inacceptables.

En conséquence, une application telle que AbiWord peut seulement employer des polices de caractères reconnues par le système d'affichage X et le langage PostScript. En pratique ceci implique utiliser soit des polices de caractères PostScript (avec extensions .pfa ou .pfb) ou, avec traitement additionnel, des polices TrueType (les polices standards dans le monde Windows, avec extension .ttf). Elle doit, en plus, être en mesure d'accéder aux fichiers de police de caractères directement ; malheureusement l'abstraction utilisée par la gestion des polices en X cache les détails à l'application, alors l'application ne peut avoir directement accès à ces fichiers et nécessite de fournir elle-même l'accès nécessaire. Dans AbiWord nous satisfaisons cette exigence en insistant sur l'utilisation de polices de caractères qui résident dans un répertoire de notre choix (AbiWord n'est pas la seule application qui utilise cette voie).

Imposer la localisation des polices dans notre répertoire de polices signifie que nous pouvons les accéder directement. Pour être capable de les utiliser pour afficher à l'écran, nous devons aussi les enregistrer pour utilisation avec le système X. Ici nous avons deux options : (1) nous pouvons insister que les utilisateurs le fassent manuellement et de manière permanente lorsqu'il ou elle installe AbiWord ; (2) nous pouvons le faire automatiquement lorsque AbiWord exécute et pour la durée de la session d'AbiWord. Les développeurs originaux ont choisi cette dernière option, probablement pour rendre l'installation et l'utilisation d'AbiWord plus facile. Malheureusement cette stratégie a des failles. L'une d'elles, l'enregistrement des polices sur le système X n'est pas simple et le processus automatique peut facilement échouer. Ce qui est plus grave, est que le processus qui fonctionne sur une saveur *nix, ne fonctionne pas sur un autre. De plus, si une police reconnue comme similaire à celle utilisée par AbiWord est déjà enregistrée sur le système, il peut arriver que lorsque AbiWord s'exécute d'autres applications démarreront en utilisant la police fournie par AbiWord à sa place. C'est une source de nombreuses plaintes des utilisateurs et la solution à ce problème sera discutée plus tard.

Besoins d'un traitement de texte WYSIWYG

Une application de disposition à l'écran tel qu'AbiWord a d'autres exigences sur l'utilisation de ses polices. Ces exigences restreignent encore plus les polices qu'elle peut utiliser et la manière de les utiliser.

AbiWord nécessite que ses polices puissent être complètement mises à l'échelle.
En tant qu'application Unicode, AbiWord a besoin de gérer des polices qui utilisent plus de glyphes que l'encodage standard Unix 8-bits fournit et ainsi permettre aux utilisateurs de créer des documents multi-langues. Cette exigence sous-tend que certaines techniques employées par des applications purement 8-bit ne peuvent être utilisées par AbiWord.
A cause de cette exigence AbiWord ne peut utiliser n'importe quel police et puisque sur les systèmes Unix/X nous ne pouvons garantir la disponibilité de polices de caractères qu'AbiWord peut utiliser, AbiWord doit s'assurer qu'il a à sa disposition au moins les polices de base. Comme la plupart des documents sont créés par des personnes utilisant MS Windows et puisque Windows fournit un jeu standard de polices nommées Times New Roman, Arial, et Courrier New, nous les avons adopter comme jeu de police de base d'AbiWord. AbiWord fournit des versions de ces polices.

Ajout et retrait des polices de caractères d'AbiWord

Comme expliqué dans une section précédente, AbiWord limite les polices qu'il rend disponible aux utilisateurs à celles localisées dans son répertoire de polices (typiquement /usr/share/AbiSuite/fonts ou /usr/local/AbiSuite/fonts, à moins que vous ne choisissiez une localisation d'installation différente) et dans le sous répertoire régional spécifique de ce répertoire. Il y installe un jeu de police de base. Vous n'êtes pas limité à l'utilisation de ces polices ; vous pouvez ajouter et retirer des polices à votre convenance. Les polices à utiliser avec AbiWord sont, cependant, limitées aux polices PostScript de Type 1 (pfa/pfb) et aux polices TrueType (ttf).

La procédure élémentaire

Si vous désirez rendre disponible à AbiWord une police additionnelle, faites ce qui suit :

(1) Placez la police dans le répertoire fonts

(2) Mettez à jours les fichiers fonts.dir et fonts.scale.

De la même façon, si vous désirez retirer une police, vous la retirez simplement du répertoire de polices d'AbiWord et vous enlevez l'entrée des fichiers fonts.dir et fonts.scale.

La procédure détaillée pour l'ajout de police pfa/pfb et pour les polices ttf est légèrement différente et est décrite plus bas. Notez aussi que la procédure est un peu plus compliquée pour les adaptations locales non-Latin1; les détails sont discutés plus loin. Si vous installez des polices autres que l'adaptation locale Latin 1, vous devriez lire Adaptations locales autres que Latin 1 en premier.

Polices de caractères pfa / pfb

Vous avez le choix, ou bien vous copiez le fichier de police de caractères dans le répertoire de police ou vous créez un lien symbolique vers le fichier s'il est localisé ailleurs sur votre système. Si votre distributeur a fourni la police avec un fichier afm, vous devriez le copier ou établir le lien tout comme pour le fichier pfa/pfb. Si non, AbiWord peut générer le fichier automatiquement, mais il est préférable d'utiliser le fichier afm fourni par le distributeur. Aussi, si un usager quelconque d'AbiWord n'a pas de permission en écriture sur le répertoire de polices, vous devez fournir les fichiers afm (votre administrateur de système peut les générer en utilisant l'utilitaire pfa2afm).

Pour mettre à jour le fichier fonts.dir, vous devriez ajouter une entrée pour désigner la nouvelle police dans fonts.scale et soit exécuter mkfontdir ou ajouter exactement la même information à fonts.dir et augmenter le nombre de polices tout au haut du fichier. Vos polices ont probablement été fournies avec un fichier fonts.dir ou fonts.scale, mais si vous ne connaissez pas ce que devrait être le contenu de l'entrée dans fonts.scale, vous pouvez la générer en employant l'utilitaire ttmkfdir (s'il vous plaît ne pas envoyer de courriel à la liste des développeurs pour obtenir l'information sur l'utilisation de ttmkfdir, consultez la documentation fournie avec ce programme).

TRES IMPORTANT !!! : Assurez-vous que vous ne modifiez pas seulement le fichier fonts.dir, mais que vous faites aussi les changements appropriés à fonts.scale. Sur certains systèmes l'utilitaire mkfontdir peut être exécuté automatiquement et puisque cet utilitaire ne gère pas les polices proportionnelles, il tronquera votre fichier fonts.dir à 0 à moins qu'il trouve fonts.scale, dans ce cas il copiera simplement le contenu de ce fichier dans le nouveau fonts.dir.

Polices de caractères TTF

** Présentement les polices de caractères TTF ne sont pas supportées par GnomePrint ; si vous utilisez Gnome, vous devez imprimer via Imprimer directement. **

Pour être en mesure d'utiliser les polices de caractères TTF avec AbiWord, deux conditions doivent être satisfaites : (1) votre serveur X doit être en mesure de gérer les polices TTF et être configuré en conséquence. Si ce n'est pas le cas, vous devriez consulter la documentation de votre distribution pour vous guider sur le processus de configuration spécifique, s'il vous plaît ne pas envoyer de courriel à la liste des développeurs sur ce sujet. (2) Votre interpréteur PostScript doit être capable de gérer les polices TTF. Les versions récentes de GhostScript ont cette capacité. Mais, vous devez l'activer au moment de la compilation et vous pouvez devoir effectuer certaines modifications au fichier de configuration de GhostScript (voir la documentation de GhostScript). Si vous utilisez une véritable imprimante PostScript, alors vous devez consulter la documentation de votre imprimante pour déterminer si elle supporte les polices de Type 42 ; les imprimantes les plus récentes ont cette capacité.

Les instructions qui suivent supposent que les deux conditions indiquées plus haut sont remplies et que vous installez les polices directement dans le répertoire de polices. Vous devriez le faire seulement si vous utilisez une adaptation locale Latin-1 ; si vous employez une adaptation locale différente, vous devriez d'abord consulter la section Adaptations locales autres que Latin 1 plus bas.

(1) Déplacez-vous dans le répertoire AbiSuite, habituellement, /usr/share/AbiSuite, ou /usr/local/AbiSuite

# cd /usr/share/AbiSuite

(2) Ce répertoire contient un certain nombre de sous répertoire, l'un d'eux est nommé fonts -- déplacez-vous dans ce répertoire.

# cd fonts

(3) Toutes les polices de caractères que vous désirez utiliser avec AbiWord doivent être copiées ou être accessible par un lien symbolique à partir de ce répertoire. Dans mon cas, elles sont localisées dans une partition Windows montée sous le répertoire /windows, alors pour la police Times New Roman je fais la commande

# ln -s /windows/windows/fonts/times.ttf times.ttf

Vous devez répéter la commande pour toutes les polices et toutes les variantes de chaque police que vous désirez utiliser (i.e., timesb.ttf pour les caractères gras de Times New Roman, etc).

(4) Maintenant vous devez modifier les fichiers fonts.scale et fonts.dir pour ce répertoire. Vous aurez besoin du programme ttmkfdir et vous trouverez les détails nécessaires dans la documentation du programme et dans la documentation de votre distribution. Une fois que ces fichiers ont été générés, vous devriez les ouvrir avec un éditeur de texte de base. Vous verrez que pour chaque police il existe de multiples entrées qui diffèrent seulement par l'encodage spécifié à l'extrémité de chaque ligne. Effacez toutes les lignes qui ne comportent pas la mention de l'encodage pour votre adaptation locale, i.e., dans mon cas toutes les lignes qui ne se terminent pas par iso8859-1 (notez qu'il existe une petite différence entre l'apparence de votre encodage LANG [ISO-8859-2] et le format d'encodage employé par les fichiers fonts.dir et fonts.scale [iso8859-1] ; ne vous en préoccupez pas).

TRES IMPORTANT : Assurez-vous que vous ne modifiez pas seulement le fichier fonts.dir, mais aussi que vous effectuez les modifications appropriés dans fonts.scale. Sur certains systèmes l'utilitaire mkfontdir peut être exécuté automatiquement et puisque cet utilitaire ne gère pas les polices proportionnelles il tronquera votre fichier fonts.dir à 0, à moins qu'il puisse trouver fonts.scale, dans ce cas il copiera simplement le contenu de ce fichier dans le nouveau fonts.dir.

(5) Maintenant déplacez-vous dans le sous répertoire bin du répertoire AbiSuite et exécutez la commande suivante :

# cd /usr/share/AbiSuite/bin

# ./ttftool -e print

Vous obtiendrez une liste d'encodages reconnus par le programme ttftool ; vérifiez si votre encodage est présent dans la liste (l'encodage de votre LANG et l'encodage employé par ttftool doivent correspondre exactement, i.e., dans mon cas je recherche ISO-8859-1). Si votre encodage n'apparaît pas, tout n'est pas perdu. Envoyez-moi un courriel et je l'ajouterai au programme, c'est très simple à faire. Si votre encodage se trouve dans la liste, alors poursuivez à l'étape suivante.

(6) Maintenant exécutez la commande suivante en fournissant le répertoire et l'encodage approprié à votre installation

# ./ttfadmin.sh /usr/share/AbiSuite/fonts ISO-8859-1

Le script ttfadmin.sh appellera le programme ttftool pour chaque police TTF de votre répertoire ; vous ne devriez pas observer d'erreur, si vous avez les permissions nécessaires pour ce répertoire (mais puisque vous venez tout juste de le créer, vous devriez).

(7) Déplacez-vous dans le répertoire de polices et observez son contenu

# cd /usr/share/AbiSuite/fonts

# ls

Vous devriez observer trois nouveaux fichiers pour chaque fichier de polices, un avec l'extension .afm, un autre avec l'extension .t42 et un avec l'extension .u2g. C'est tout. Vous avez terminé. Démarrez AbiWord, n'oubliez pas de définir la variable LANG auparavant si nécessaire.

Adaptations locales autres que Latin-1

Si vous installez une police de caractères pour un encodage autre que iso8859-1, les choses sont un peu plus compliquées. Premièrement, vous devriez installer la police dans un sous répertoire nommé comme votre adaptation locale. Par exemple, si vous utilisez l'adaptation locale Hébraïque, vous créez le répertoire ISO-8859-8 à l'intérieur du répertoire de polices d'AbiWord. Le nom de ce répertoire doit correspondre exactement à l'encodage fourni par votre variable d'adaptation locale. Si vous utilisez Bash, faites

# echo $LANG

Vous devriez obtenir un résultat similaire à celui-ci

# iw_IL.ISO-8859-8

Il est important que l'encodage (la partie après le point) soit spécifié explicitement, i.e., si vous observez quelque chose tel que

# iw_IL

C'est un signe que ca ne fonctionnera pas. En définissant la variable LANG avant de démarrer AbiWord est facile, dans Bash faites

# LANG=iw_IL.ISO-8859-8

# export $LANG

Vous n'avez pas à effectuer une modification de la variable $LANG qui couvre le système en entier, tout ce qui est requis est que la variable soit définie avant d'exécuter AbiWord. Personnellement, j'utilise un court script pour exécuter l'adaptation locale Czech d'AbiWord que j'appelle abicz. Il comporte le contenu suivant :

#!/bin/sh

LANG=cs_CZ.ISO-8859-2

export $LANG

abiword

Ainsi je n'ai pas à changer la définition habituelle de LANG et n'ai pas à me rappeler de la modifier manuellement lorsque je désire exécuter l'adaptation locale Czech d'AbiWord.

Si vous ajoutez une police de type TTF, alors tout ce que vous devez faire maintenant est de suivre les instructions du guide d'installation TTF plus haut, au lieu du répertoire de polices, vous installez les polices dans le répertoire de l'adaptation locale spécifique.

Si vous utilisez une police pfa ou pfb, vous devez suivre les instructions dans la section police de caractères pfa/pfb plus haut, et faire aussi quelques petites actions supplémentaires. Premièrement, lors de l'ajout d'entrées pour la police dans fonts.scale (et fonts.dir) assurez-vous que l'encodage, i.e., les deux dernières parties de la ligne séparées par des traits d'union sont définies comme adobe-fontspecific. Ensuite, vous avez à créer un fichier nommé fonts.alias dans lequel vous créez un alias à la police avec l'encodage réel qu'il représente. Par exemple si votre police se nomme BLAH est pour iso8859-8, l'entrée dans fonts.scale/fonts.dir devrait ressembler à ceci :

blah.pfa -...-BLAH-.........-adobe-fontspecific

(les points représentent ce qui constitue votre entrée spécifique). Vous devez créer un fichier fonts.alias qui devrait contenir la ligne suivante :

"-...-BLAH-.........-iso8858-8" "-...-BLAH-.........-adobe-fontspecific"

En ce qui concerne les polices, c'est tout. Cependant, vous pouvez consulter la section Problèmes reliés au clavier qui traitent de problèmes particuliers que vous pouvez rencontrer. Autrement, vous pouvez démarrer AbiWord et les nouvelles polices de caractères devraient apparaître dans la liste déroulante.

Particularités Unicode

Même si AbiWord ne fournit pas un support complet de l'adaptation locale utf-8, il est capable de traiter les documents contenant des caractères arbitraires du jeu UCS-2 si l'encodage de l'adaptation locale est fixée à utf-8. Cependant, il peut le faire seulement avec des polices Unicode. Afin de permettre au système X de traiter une police en tant qu'Unicode, vous devez spécifier l'encodage dans XLFD (l'entrée dans le fichier fonts.dir/fonts.scale) en tant que iso10646-1. Pour vérifier si votre police est reconnue comme une police Unicode exécutez :

#xlsfonts -ll -fn font_name

Cette commande produira beaucoup d'information à propos de votre police et parmi, vous trouverez les valeurs de min_byte1 et max_byte1 ; si ces deux valeurs sont 0, alors votre police est reconnue comme police 8-bit seulement. Selon mon expérience, il est impossible d'utiliser une police pfa de Type 1 ou 2 sous XFree86 4 en tant que police Unicode (si vous connaissez la méthode pour que XFree reconnaisse une police pfa en tant que police Unicode, veuillez m'en informer afin que je puisse mettre à jour ce document), ce qui signifie que vous serez limité à des polices TTF seulement.

Problèmes au paradis

Mes polices de caractères pour l'encodage XXX s'impriment comme des cercles mais s'affichent correctement

Symptômes : vous avez installé une police personnelle pfa/pfb pour un autre encodage que Latin-1 (habituellement ISO-8859-2) et même si tout fonctionne bien à l'écran vous obtenez des cercles au lieu de caractères (accentués) lorsque vous imprimez le document. La police fonctionne correctement avec d'autres applications. (NB : si vous observez des cercles à l'écran, il s'agit d'un autre problème.)

Diagnostic : Même si ce problème peut à l'occasion être relié à l'utilisation du clavier, la plupart du temps, il est causé par votre police de caractères. Pour faire la distinction entre les deux causes, vous devriez effectuer l'essai suivant. Créez un nouveau document AbiWord et entrez quelques lettres dans votre langue (celles qui apparaissent imprimées comme des cercles). Enregistrez le document dans le format abw et ouvrez-le avec un éditeur de texte de base. Au début du document se trouve un en-tête et par la suite vous trouverez vos caractères entre une paire de balises <c></c>. Dans un document normal d'AbiWord, créé avec une adaptation locale 8-bit, chacun de ces caractères devrait être représenté par un seul octet et vraisemblablement vous seriez capable de les lire. Si c'est le cas, alors lisez la suite. Cependant, si vous observez que les caractères sont représentés par un jeton &#xXXXX (où XXXX est la valeur Unicode du caractère), alors votre problème est relié au clavier et vous devriez consulter la section Problèmes reliés au clavier plus loin.

Cause : votre police est défectueuse. Elle a probablement été créée suite à la modification d'une police originale Latin-1. Même si la personne qui a effectué la modification a changé les glyphes, il ou elle n'a pas modifié le nom du glyphe. La police fonctionne avec d'autres applications (8-bit) parce qu'elles utilisent des codes de caractères 8-bit pour accéder aux glyphes, en supposant que les premiers 256 glyphes de la police et que son fichier de métrique sont ordonnés selon l'encodage de l'adaptation locale présente. Cette supposition n'est pas sécuritaire et AbiWord ne peut se permettre de la faire. En effet, nous supportons des adaptations locales autres que 8-bit et des polices qui contiennent plus de 256 glyphes qu'une application 8-bit utiliserait (par exemple la police MS Times New Roman contient près de 1200 glyphes). La seule manière fiable par laquelle nous pouvons retrouver l'information de métrique des glyphes dans le fichier de métrique, est en employant le nom de glyphe. Dans le cas une police pfa/pf, Adobe spécifie une conversion sans ambiguïté entre ses noms de glyphe standard et Unicode et nous utilisons cette conversion pour traduire la valeur d'Unicode en nom de glyphe. Si les glyphes dans votre police ne sont pas nommés correctement, le glyphe que nous recherchons selon le standard PostScript Adobe, n'est pas retrouvé dans la police alors nous dessinons un petit cercle à sa place.

Solution : même si le problème n'est pas de la responsabilité d'AbiWord, nous fournissons une voie de contournement pour de telles polices défectueuses. Vous devez créer un fichier u2g qui porte un nom identique à celui de la police, i.e., si votre police est nommée amaretto.pfa, vous devez la nommer amaretto.u2g. Vous devez spécifier la conversion entre le nom de glyphe et la valeur Unicode que la police utilise. Chaque ligne du fichier u2g qui débute par le caractère # est considérée un commentaire et est ignoré, la première ligne qui n'est pas un commentaire doit contenir le nombre de conversions (i.e., lignes) qui suivent. Chaque entrée comporte le nom de glyphe suivi d'une virgule et de la valeur Unicode en hexadécimal. Chaque entrée doit être sur sa propre ligne et ordonnée alphabétiquement selon le nom de glyphe. Vous pouvez utiliser le fichier adobe-full.u2g, localisé dans le répertoire de polices comme un exemple. Si vous avez plusieurs polices qui utilisent le même nom de glyphe erroné, vous pouvez créer un seul fichier et créer un lien symbolique pour les autres fichiers. Si toutes les polices de votre répertoire emploient le même nom de glyphe erroné, vous n'avez pas à créer des liens symboliques, nommez le fichier locale.u2g.

Lorsque j'entre des caractères, j'obtiens des petits cercles à l'écran

Symptômes : lorsque vous entrez des caractères au clavier, certaines ou toutes les lettres apparaissent comme des petits cercles à l'écran.

Diagnostic : ce problème peut être relié au clavier ou provenir de votre police. Pour en identifier la cause, vous devriez effectuer l'essai suivant. Créez un nouveau document AbiWord et entrez quelques caractères dans votre langue (celles qui apparaissent comme des cercles). Enregistrez le document en format abw et ouvrez le avec un éditeur de texte de base. Au début du document se trouve un en-tête et par la suite vous trouverez vos caractères entre une paire de balises <c></c>. Dans un document normal AbiWord créé avec une adaptation locale 8-bit, chacun des caractères devrait être représenté par un seul octet et vraisemblablement vous devriez être en mesure de les lire. Si c'est le cas, alors lisez la suite. Cependant, si vous observez que les caractères sont représentés par un jeton &#xXXXX (où XXXX est la valeur Unicode du caractère), alors votre problème est relié au clavier et vous devriez consulter la section Problèmes reliés au clavier plus loin.

Cause : le petit cercle est une indication que le glyphe requis n'a pas été trouvé dans la police présente. Vous pourriez, par exemple, demander un caractère du jeu Latin 2 alors que vous avez à votre disposition seulement les polices Latin 1 par défaut.

Solution : Si vous désirez utiliser AbiWord avec une adaptation locale qui nécessite un encodage différent de Latin 1 vous devez fournir vos propres polices. Vous devez suivre la procédure décrite à Ajout et retrais des polices de caractères à AbiWord, incluant les instructions de la section Adaptations locales autres que Latin 1.

Problème "Abiword fait du gâchis avec mes polices de caractères"

Symptômes : lorsque je démarre l'application XXX pendant qu'AbiWord fonctionne, ses polices apparaissent en forme de poires ; dans des cas extrêmes ce symptôme apparaît lorsque'AbiWord n'est pas en cours d'exécution.

Cause : certaines polices sur votre système portent des noms identiques à certaines polices d'AbiWord et l'application XXX emploie les polices d'AbiWord au lieu des polices qu'elle employait normalement.

Solution : si vous ne voulez pas que les autres applications emploient les polices d'AbiWord, vous devez faire en sorte qu'AbiWord emploie les polices déjà présentes sur votre système ; AbiWord peut gérer les polices Type1 et TrueType. Voici les instructions pas à pas :

(1) Déplacez-vous dans le répertoire de polices d'AbiWord, habituellement /usr/share/AbiSuite/fonts or /usr/local/AbiSuite/fonts.

(2) Ouvrez le fichier fonts.dir avec votre éditeur de texte préféré.

(3) Identifez la ou les polices en problème. Par exemple. Supposons que vous avez la police MS Arial installée, mais qu'AbiWord fait que vos autres applications emploient une autre police Arial que vous ne trouvez pas aussi attrayante. Dans ce cas localisez les lignes :

n019003l.pfa -AbiSource-Arial-regular-r-normal--0-0-0-0-p-0-iso8859-1

n019004l.pfa -AbiSource-Arial-bold-r-normal--0-0-0-0-p-0-iso8859-1

n019023l.pfa -AbiSource-Arial-regular-i-normal--0-0-0-0-p-0-iso8859-1

n019024l.pfa -AbiSource-Arial-bold-i-normal--0-0-0-0-p-0-iso8859-1

et modifiez-les pour un contenu plus approprié pour votre police (puisque vous avez la police installé, il existe un fichier fonts.dir dans ce répertoire avec toutes les informations nécessaires) ; dans le cas d'Arial l'information devrait être similaire à ceci :

arial.ttf -monotype-Arial-medium-r-normal--0-0-0-0-p-0-iso8859-1

arialb.ttf -monotype-Arial-bold-r-normal--0-0-0-0-p-0-iso8859-1

ariali.ttf -monotype-Arial-medium-i-normal--0-0-0-0-p-0-iso8859-1

arialbi.ttf -monotype-Arial-bold-i-normal--0-0-0-0-p-0-iso8859-1

(Au lieu de copier, vous devriez trouver le fichier fonts.dir de votre système dans lequel la police est décrite et copiez-en son contenu.)

(4) Créez des liens symboliques nommés arial.ttf, arialb.ttf, etc., dans le répertoire de polices d'AbiWord, faites pointer le lien là où sont localisés les fichiers de polices désirés. Si la police en question est de Type1 (pfa/pfb), vous devez créer un lien symbolique au fichier afm, qui devrait être localisé dans le même répertoire que la police elle-même ; si la polices en question est de type TrueType, comme dans l'exemple plus haut, vous devez suivre les instructions localisées dans la première section de ce document et exécuter le script ttfadmin.sh.

(5) Vous pouvez le faire pour chaque police d'AbiWord décrites dans le fichier fonts.dir, cependant ceci peut créer des problèmes à l'utilisation de listes à puces dans AbiWord. En plus, notez que si AbiWord ne peut trouver une police requise par un document, il essaiera d'employer la police Times New Roman et s'il ne peut trouver l'une ou l'autre il emploiera la première police qu'il peut trouver. Alors, si vous éliminez l'entrée Times New Roman assurez-vous que la toute première police énumérée dans le fichier fonts.dir est une police normale et non une police de symboles.

(6) Si vous n'employez pas l'une des polices originales, i.e., toutes les polices de votre fichier fonts.dir sont physiquement localisées ailleurs que dans le répertoire de polices d'AbiWord et sont déjà accessibles à votre application par l'intermédiaire de X, il n'est pas nécessaire ou désirable de modifier le chemin d'accès aux polices de X. Pour empêcher AbiWord de le faire, allez à l'item Option du menu Outils, sur l'onglet Thème désactivez la case Modifier le chemin d'accès aux polices de caractères Unix puis commentez les lignes xset fp du script de démarrage d'AbiWord (localisé dans le répertoire AbiSuite/bin).

Problèmes reliés au clavier

Strictement parlant, cette section ne devrait pas faire partie d'une page d'aide traitant des problèmes de polices de caractères, mais à cause des manifestations des problèmes décrits plus bas, la vaste majorité des utilisateurs considéreront ces manifestations comme un problème de police, il est donc approprié de traiter de ce sujet ici.

Symptômes : (1) Vous obtenez de petits cercles au lieu des caractères à l'écran ou vous voyez les caractères appropriés à l'écran mais, à l'impression du document vous obtenez des petits cercles pour certain, plusieurs ou tous les caractères. (2) Vous vous voyez des caractères incompréhensibles avec Abiword sous Windows alors que vous avez créé votre document avec AbiWord sous Linux.

Diagnostic : il existe un essai simple à effectuer. Créez un nouveau document AbiWord et tapez quelques caractères dans votre langue. Enregistrez le document en format abw et ouvrez-le avec un éditeur de texte de base. Au début du document se trouve un en-tête et par la suite vous trouverez vos caractères entre une paire de balises <c></c>. Dans un document normal AbiWord chacun des caractères devrait être représenté par un seul octet et vraisemblablement vous devriez être en mesure de les lire. Cependant, si vous observez que les caractères sont représentés par un jeton &#xXXXX (où XXXX est la valeur Unicode du caractère), alors votre problème est celui que nous traitons ici, autrement vous consultez la section Mes polices de caractères pour l'encodage XXX s'impriment comme des cercles mais s'affichent correctement.

Cause : Il semble que plusieurs des distributions pré-assemblées de Linux ne configurent pas correctement le clavier si vous utilisez une langue autre que l'anglais. Le système X supporte un grand nombre de caractères et nomme chacun. Par exemple, le caractère Unicode u05d0 qui représente la lettre Aleph en Hébreu est reconnu par le serveur XFree comme hebrew_aleph. Lorsque vous désirez entrer le caractère Aleph en Hébreu le clavier doit émettre ce caractère spécifique à l'intention du serveur X. L'association d'une touche particulière à un caractère particulier est effectuée par ce qui est appelé xmodmap. Ce fichier spécifie quel caractère chaque touche du clavier génère. Par exemple, il associe la touche qui serait 't' sur le clavier anglais avec la lettre Aleph du clavier Hébreu.

La manière correcte pour réaliser l'assignation est de faire correspondre la touche (touche no. 28) au nom du caractère hebrew_aleph. Lorsqu'une application 8-bit, telle que le terminal demande un caractère au serveur X, le serveur traduit le code hebrew_aleph au jeu de caractère que le terminal emploie, probablement ISO-8859-8 et émettra ainsi au terminal le code 0x00e0. Une application Unicode demandera le code de touche tel quel et le traduira de manière interne à la valeur Unicode (soit par appels supplémentaires au système X ou, tel qu'AbiWord le réalise, en consultant une table interne). Dans notre cas, nous effectuons une traduction du code hebrew_aleph à la valeur Unicode 0x05d0.

Malheureusement, il arrive souvent qu'au lieu d'employer le nom du caractère X, xmodmap assigne à la touche une valeur numérique au caractère pris à partir du jeu de caractères 8-bit de la langue, e.g., dans notre exemple la touche 28 est associée à la valeur 0x00e0, i.e., le code pour Aleph dans le jeu de caractère ISO-8859-8. Le problème est que pour le serveur X, la valeur 0x00e0 n'est pas Aleph, mais le caractère a accent grave. Maintenant, lorsqu'une application 8-bit demande des caractères au serveur, il émettra cette valeur numérique et tout semblera parfait. Cependant, lorsqu'une application Unicode telle qu'AbiWord demande un caractère, le serveur lui émettra également cette valeur numérique qui traduira de manière interne en Unicode, ce qui nous donne le caractère Unicode 0x00e0. Puisque ce caractère n'existe pas dans la police ISO-8859-8 que vous utilisez probablement lorsque que vous affichez en Hébreu, vous verrez un petit cercle (quelques fois, si vos polices ne sont pas configurées convenablement elles aussi, vous verrez votre texte correctement à l'écran mais vous obtiendrez de petits cercles à l'impression).

Solution : Vous devez régler l'assignation de votre clavier. Comment faire dépend de votre environnement. Si vous utilisez certains utilitaires clavier tel que kikbd qui est fourni avec KDE, vous devrez modifier le fichier de configuration de l'utilitaire, si vous utilisez xmod, vous devez modifier le fichier xmodmap qui contient la définition de clavier. En ce qui concerne AbiWord, vous avez deux options ; soit vous utilisez le nom de caractère tel que décrit plus haut (vous trouverez le nom dans la documentation du serveur X) ou vous pouvez assigner la valeur 0x0100XXXX à la touche, où XXXX est le code Unicode du caractère (e.g., 0x010005d0 pour Aleph en Hébreu). Cette dernière méthode a l'avantage que vous pouvez même assigner des caractères pour lequel le système X ne possède pas de nom, mais vous devriez être conscient que toutes les applications ne sont pas en mesure de gérer les claviers définis de cette façon.