Archive Liste Typographie
Message : [K2] Attributs de style [I.1.a] (long)

(Olivier RANDIER) - Mardi 24 Février 1998
Navigation par date [ Précédent    Index    Suivant ]
Navigation par sujet [ Précédent    Index    Suivant ]

Subject:    [K2] Attributs de style [I.1.a] (long)
Date:    Tue, 24 Feb 1998 02:19:59 +0100
From:    Olivier RANDIER <orandier@xxxxxxxxxxx>

I - Typographie
I.1 - Gestion typographique de base
a) Attributs de style

La logique des attributs de style, qui trouve ses origines dans la ToolBox
d'Apple, il me semble, a atteint sa limite. S'agissant de traitement
typographique pointu, il faut s'en affranchir pour progresser. Ses défauts
principaux : son caractère binaire (oui/non) et sa limitation.

Graisse
L'attribut « Bold » n'est pas suffisant pour gérer des polices aux graisses
multiples, comme beaucoup le sont aujourd'hui. Certes, il faut conserver
des couples gras/non gras logiques, mais il serait souhaitable de pouvoir
naviguer dans les graisses par incrément, via un raccourci clavier et un
curseur sur une échelle graduée et de pouvoir modifier ponctuellement la
graisse appelée par l'attribut « Bold ».
Exemple des attributs :
<gras>
<graisse= 4/5>
<gras, graisse=+3>

Voir aussi le paragraphe Gestion avancée des Multiple Masters de ce même
chapitre.

Italique/oblique
L'attribut italique est source de nombreuses erreurs, car il permet souvent
d'afficher l'italisation d'une police qui ne possède pas de version
italique, ce qui est une entorse au WYSIWYG. Il serait souhaitable que ne
soit possible que l'affichage de polices existantes (c'est valable aussi
pour le gras).
Il faudrait distinguer la fonction standard d'italisation de celle
d'« obliquisation » qui permettrait de pencher une police ne comportant pas
d'italique.
Ce qui donnerait deux attributs :
<italique>
<oblique, angle = x°>

Relief (Outline)
Bien que cet attribut soit fort peu typographique, il est devenu, hélas,
incontournable. Puisqu'il serait difficile aujourd'hui d'en faire admettre
la disparition, autant qu'il soit géré convenablement. Rappelons que le
filetage doit être extérieur à la lettre, et non à cheval sur son contour.
Il serait souhaitable que l'épaisseur de ce fileté soit paramétrable (ce
qui n'est pas le cas dans XPress) et que sa couleur puisse être définie de
manière distincte du fond de la lettre (idem), qui peut éventuellement être
transparent.
<outline, épaisseur de filet=a, couleur de filet=b, couleur de fond=c>
À noter que la traduction française usuelle de ce terme (relief) est absurde.


Ombré (Shadow)
Attribut aussi douteux typographiquement que le précédent. Inutilisable en
l'état actuel, car aucunement paramétrable. Les graphistes ont recours pour
faire des ombrés complexes à des utilitaires de tierce partie (ex. :
ShadowCaster), qui génèrent des images bitmap. Il serait souhaitable,
plutôt, de pouvoir paramétrer directement angle et distance de décalage de
l'ombre, ainsi que sa couleur et sa valeur de flou éventuel. Le tout étant
enregistrable comme paramètre typographique local (feuille de style) et
générant simplement le code postscript adéquat à l'impression.
<ombré, angle=a°, distance=b, rayon de flou=c, couleur de la lettre=d,
couleurs de l'ombre=e, f>

Souligné/barré
L'attribut de soulignement fait intervenir une fonction postscript
simpliste, intégré au format de fonte, qui consiste simplement en une
épaisseur relative au corps et une hauteur relative à la ligne de base. Le
résultat est généralement laid. Il serait préférable (certaines XTensions
le font plus ou moins bien) de pouvoir spécifier soi-même épaisseur,
distance de la ligne de base, et, éventuellement couleur. Dans ce dernier
cas, il faut pouvoir préciser si le filet est devant ou derrière la
lettre ! Une option importante serait de pouvoir interrompre le filet
chaque fois que celui-ci rencontre une partie de lettre (descendante, en
général), en spécifiant la distance par rapport à celle-ci <ici, je prévois
un schéma, je ne suis pas sûr d'être clair>.
<souligné, distance=a, épaisseur=b, couleur=c, plan=devant/derrière>
Barré et mot souligné ne sont qu'anecdotiques, et peuvent être considérés
comme des variantes du soulignement.
À noter que Souligné ne devrait pas être un attribut de la lettre, mais de
la ligne, parce que, si on souligne un texte comportant des indices ou des
exposants, on a des surprises désagréables...

Tout capitales
Rien de particulier à dire sur cet attribut, excepté qu'il doit
impérativement respecter l'accentuation des bas-de-casse (c'est
généralement le cas, heureusement), sauf si c'est spécifié par
l'utilisateur. Dans le cadre du support multilingue, il doit gérer
correctement les translittérations (par ex. : ß = SS, en allemand). Il faut
aussi gérer de façon pointue la distinction entre l'attribut de style Tout
caps et le changement de casse brut.

Petites caps
L'horreur absolue ! Cet attribut, qui ne provient pas de la ToolBox, est un
bricolage immonde, qui procède par réduction (paramètrable) des capitales,
d'où incohérence des graisses relatives.
Deux solutions :
- pour les fontes possédant une graisse Expert, un lien comme celui qui
existe entre romain et italique d'une même fonte permettrait de résoudre le
problème (modification des spécifications de format du Type 1 ?). Resterait
toutefois le problème de certains signes de ponctuations (apostrophe, point
d'interrogation, d'exclamation, etc., qui ne sont pas nécessairement dans
la casse approprié dans ce cas).
Une translittération par Unicode (voir chapitre I.3), du même type que
celle qui intervient (en 8 bits) avec l'attribut Tout caps permettrait de
résoudre le problème de façon élégante, en conservant aussi la distinction
utile entre attribut ponctuel et changement de casse.
- pour les fontes Multiple Masters (voir la section consacrées à
celles-ci), en l'absence de vraies petites caps, celles-ci pourraient être
générées par calcul d'une instance sur les axes corps et graisse.
La hauteur des petites caps devrait alors être automatiquement calculée par
rapport à la hauteur d'oeil des bas-de-casse, sauf spécification contraire
de l'utilisateur.

Exposant/indice/supérieur
Mêmes problèmes que ceux posés par les petites caps. Mêmes solutions*,
donc. De plus, pour les deux premiers, il faut noter que leur paramètrage
(réduction + décalage vertical) laisse la place à un arbitraire douteux.
Pour l'exposant, XPress a introduit une amélioration avec l'attribut
Supérieur, qui n'a qu'un paramètre de réduction de taille, le décalage
vertical étant calculé de manière à aligner le supérieur sur la hauteur
d'oeil des capitales, ce qui est typographiquement correct. Ceci pourrait
être étendu aux indices (alignement sur les descendantes).
D'autre part, dans le cadre de la composition scientifique, il faudrait que
ces attributs puissent être cumulatifs (exposants et indices à multiples
niveaux), avec une limite de corps (absolue). De plus, il faudrait pouvoir
spécifier les paramètres localement (feuilles de style) et non au niveau de
tout le document (comme c'est le cas dans XPress). Bien entendu, ce
paramètrage doit pouvoir se faire en relatif (%, par défaut), comme en
absolu (corps).

* Toutefois, la solution Multiple Masters serait préférable, car elle
éviterait de surcharger Unicode, avec d'innombrables variations de casse.

Ceci clôt la liste des attributs courants de style de la ToolBox, mais pas
celle des attributs qui seraient souhaitables pour gérer les problèmes
typographiques plus complexes, notamment la composition scientifique. Nous
n'allons pas énumérer ici tous les attributs envisageables (ce serait
d'ailleurs sans doute impossible). Nous y reviendrons dans la section I.2.a.

b) Architecture d'attributs de style

Notons quand même que les attributs devraient reposer sur une architecture
ouverte, avec une interface de « programmation », pour résoudre des
problèmes spécifiques.
Celle-ci doit permettre d'accéder à des paramètres plus variés, par exemple :
- extension d'un caractère sur plusieurs lignes (accolades, intégrales, etc.),
- Position relative à un caractère, un mot ou une expression sélectionnée
(exposant et indice simultanés, vecteurs, position de la barre de fraction
par rapport au signe égal, etc.),
- Décalage horizontal,
- Rotation,
- Symétrie,
- Inclinaison,
- ...

Ceci implique de pouvoir s'affranchir ponctuellement de la logique linéaire
de composition (alignement de bounding boxes les unes derrière les autres).

______________________________

Olivier RANDIER -- Experluette		mailto:orandier@xxxxxxxxxxx
		http://perso.wanadoo.fr/thierry.vidal/
Claviers et scripts WorldScript translittérés pour faciliter la composition
des langues est-européennes, du grec et du cyrillique.