Re: [typo] Especes d'espaces...

[Thierry Bouche <tbouche@xxxxxxx>]

Le mercredi 4 août 2004 à 09:54:14, Alain écrivit :

>>espaces mot invariables : typiquement après une puce en début de
>>ligne (en fait on utilise en général une insécable, mais ça ne devrait
>>pas être utile),
>>
AH> J'avais rectifié mon lapsus sur la variance !

AH> Un autre cas, c'est l'espace après le tiret d'incise qui précède une réplique
AH> dans un dialogue.

s'appelle-t-il encore le tiret d'incise dans ce cas ? Oui, c'est le
même cas (si ce n'est que dans une liste où la « puce » est le tiret
ou dans des dialogues, l'espace après est nécessairement l'espace mot,
tandis qu'avec une puce dingbat, on peut très bien vouloir d'autres
espacements : il me semble que le coup de la tabulation convient bien
dans ce deuxième cas)

> Espace
AH> invariable, donc, et placement automatique d'icelle (est-ce que T*X*** sait
AH> faire ça automatiquement ? Pas XP*****, ni à ma connaissance ID***)

pas vraiment de réponse à ça : soit tu saisis le dialogue comme une
liste, et tu as dans tes paramètres de liste comme ça, soit tu insères
l'espace que tu veux au bon endroit :

---\Kr Oui ?...

je ne vois pas trop ce que ça pourrait vouloir dire, automatique, dans
ce cas : il faut bien que quelqu'un dise qu'il s'agit d'un dialogue et
qu'il faut un tiret suivi d'une espace fixe.

>>en revanche, on peut préférer disons une
>>espace insécable qui se rétrécit à la même vitesse que les
>>justifiantes de la même ligne
>>
AH> Là aussi, je suis d'accord : un genre d'insécable variable, mais qui rétrécit
AH> moins que la sécable. Que se passe-t-il quand les espaces s'élargissent ? ça
AH> arrive aussi, tu sais ?

Bon, tu as lu en diagonale et supprimé de ta citation la réponse à ta
question...

je proposais : rétrécissement aussi rapide (pour pas se retrouver avec
une espace plus forte là où le lien devrait justement être plus
serré), élongation plus lente (pour la même raison).

Il se trouve que je peux faire une telle espace en un rien de temps
avec tex (ce que j'appelle fondre mes semijustifiantes), et l'utiliser
sans même attendre que le plomb refroidisse ! C'est même cadeau en
standard dans l'espacement des guillemets pour les utilisateurs de
latex via frenchb/babel. (et on peut évidemment s'en fondre
quelques-unes et les employer automatiquement devant certaines classes
de ponctuation).

Je vais me permettre une petite digression sur les espaces dans TeX
parce que je crois que ça en vaut la peine pour le sujet. La grande
question, ensuite, c'est comment on met une chose pareille dans une
interface wysiwyg (mais en fait, il suffirait de pouvoir ouvrir une
boite dans laquelle on définisse l'espace en question en lui donnant
un nom, et de pouvoir lui associer un raccourci clavier). De façon
générale, ce genre de possibilité dans les logiciels de PAO pourrait
faire exploser le niveau de qualité possible. Je persiste à penser que
l'interface wysiwyg est un carcan qui rend souvent impossible à
l'utilisateur de paramétrer un moteur de composition beaucoup plus
flexible que ce que l'interface autorise à faire. Analogie toujours
avec les synthétiseurs qui peuvent faire toute la gamme micro-tonale,
et qui sont livrés avec un clavier bien tempéré !

Donc, tex a d'abord un ensemble de dimensions dans lesquelles
l'utilisateur peut piocher pour définir des espaces, ces dimensions
sont notamment : le petit point (il en faut quelques millions pour
faire un pouce), le point pica (72,27 pour un pouce), le gros point
(ou point PAO : 72 pour un pouce), le point didot, le millimètre et le
pouce. Ce sont des dimensions « fixes » à cela près qu'on peut zoomer
la page produite, évidemment. Ensuite, tex fournit à ses utilisateurs
des dimensions extrêmement pratiques pour créer des blancs qui
survivent aux changements de corps ou de police : ex (hauteur d'x de
la police *courante*), em (cadratin de la police *courante* ou, si
l'on préfère, valeur du corps utilisé -- mais c'est une valeur
déclarée dans la police, et c'est donc au dessinateur de la police de
choisir s'il donne une valeur différente du corps). Ensuite de cet
ensuite, il y a des dimensions infinies : fil et fill qui suivent les
règles d'arithmétique : fini + infini = infini (fill est infiniment
plus infini que fil, ça permet de mettre un blanc infini quelque part
dans une maquette et de l'écraser à l'utilisation). C'est comme ça
qu'on implémenterait l'« espace sans alinéa » d'ID. Ensuite de tout
ça, tex stocke dans des registres les valeurs en cours d'utilisation,
comme par exemple toutes les métriques d'une police, or c'est chaque
police qui définit elle-même le bon usage qu'on doit en faire : espace
mot idéale, valeurs minimale et maximale, on peut donc également
récupérer ces valeurs d'abord parce qu'on peut très bien décider de
les modifier (on charge la fonte, et on définit les registres
correspondants à 80 % de ceux lus dans la police, p. ex., ou on double
l'espace mot idéale sans toucher à ses paramètres d'élasticité, etc.)

Par exemple, la définition de \Kr comme espace fixe insécable de la
valeur de l'espace mot idéale de la police en cours pourrait être :

\def\Kr{\kern\fondimen2\font}

(un \kern est un crénage fixe, à utiliser avec parcimonie et de façon
insécable, car il ne disparaît pas en début de ligne si ça coupe !)

l'espace semijustifiante insécable pour les guillemets français est
celle-ci :

   \def\guill@spacing{%
  % insécable : pénalité maximum en cas de coupure
   \penalty\@M
  % \hskip fait une espace horizontale élastique
   \hskip
  % valeur « au repos » : 80 % de la deuxième dimension enregistrée
  % dans la fonte courante : espace mot idéale de ladite fonte
   .8\fontdimen2\font
  % qui peut s'élargir jusqu'à 30 % de l'élasticité autorisée pour
  % l'espace mot standard
    plus.3\fontdimen3\font
  % et qui se contracte comme l'espace mot (réduite à 80 %)
    minus.8\fontdimen4\font}

Vu comme ça, c'est un peu effrayant, mais j'ai désormais un nom de
macro (p. ex. \Kr) que je peux saisir dans mon texte là où je veux
l'espace en question : pas plus compliqué que de taper sur une touche
spéciale ou aller dans un sous-menu pour sélectionner un glyphe
étrange ; et je peux évidemment lui allouer un raccourci clavier dans
mon éditeur de texte si je dois m'en servir souvent.


[la valeur de la fine]
AH> Il y aurait de quoi en faire un long article, mais je doute qu'il intéresse
AH> beaucoup le vaste peuple.

on devient consuméristes, sur cette liste ?


>>Chose acquise :
>>
>>du temps du plomb (Lefevre, disons) : fine = 1 pt, pouvant aller à 2,
>>
AH> Ça me semble difficile de comparer.

AH> En compo froide, que nos grands anciens me détrompent si nécessaire, la
AH> justification se faisait à l'aide des espaces. Un typo habile, pour une compo
AH> élégante, équilibrait les espaces, les fines et tout le toutim pour leur donner
AH> des valeurs équivalentes au moins au sein d'une même page : résultats
AH> magnifiques. Dans une compo pourrie, il faisait ce qu'il voulait (et c'était
AH> parfois un peu... étrange, au final).

AH> De nos jours, le problème se pose tout à fait différement puisque les logiciels
AH> agissent sur tout un tas de paramètres évidemment innaccessibles quand la
AH> composition était « matérialisée ».

euh, je comprends rien à ton doux sabir. Le moteur de composition est
supposé être un « système expert » qui a modélisé le fameux travail du
typo plomb et cherche donc à faire la même chose. La grosse vraie
question est simplement comment on prépare la « copie » pour que ce
système sache ce qu'il faut faire, et comment. Si je veux une fine de
0,5 pt avant la virgule, mais qui soit autorisée à se réduire en cas
d'urgence, mais pas à se dilater, je suis dans la position du prote qui
dit ça au compositeur, et qui attend qu'il applique avec sagacité ces
règles. Donc, non, le paradigme est le même, sauf qu'on a une
flexibilité supplémentaire due à la dématérialisation des caractères,
et une communication plus difficile avec le ventre de l'ordinateur
(due à des interfaces conçues pour des mal comprenants informatiques
pas forcément au courant de la notion de copie préparée).

AH> Autre élément : nous faisons désormais considérablement varier les forces de
AH> corps, selon les boulots et parfois au sein d'une même page

AH> Moyennant quoi, nous avons désormais besoin d'une définition _générale_ de la
AH> fine, quel que soit la force de corps. Lefevre naviguait en composition
AH> courante entre du corps 10 et du corps 12 : une fine d'un ou deux points lui
AH> allait fort bien (surtout avant les virgules, surtout si le but du jeu était de
AH> pouvoir les ôter en cas de problème avec la justification, etc.)

ben tu traduis donc 1 pt par em/10 et hop
(ou em/9 si t'es Tschicholdien)

AH> Dernier point : les temps changent, la perception du gris typographique aussi.
AH> Pas sûr que de nos jours, seraient admis comme simplement _acceptables_ les
AH> espaces et les fines de la compo bas de gamme du XIXe siècle.

ça... c'est vrai qu'on voit moins de lézardes, au final, mais pour les
espaces, il semblerait que le lecteur de Libé avale vraiment tout,
non ?


[Tsch**]
AH> Mon souvenir est quand même qu'il parle de la beauté de l'espace égale au _i_,
AH> de sa parfaite adaptation au texte courant et au livre (en tout cas en allemand
AH> : mots longs et problèmes de césures). Qu'il milite pour un rétrécissement de la
AH> valeur de l'espace, remarquant la tendance générale (et hélas ! pas démentie :
AH> plus ça va, plus elles sont grandes) d'un élargissement parfaitement
AH> regrettable.

oui.

AH> M/3, tu dis ? Ça dépend de la chasse du M, évidemment

Non, non : ici M = em = cadratin. (qui n'est *pas* la chasse du M,
combien de fois ai-je lu cette erreur !)

AH> Quand à _em_, bien malin qui nous dira combien il vaut : c'est
AH> écrit dans la BoudingBox, c'est ça ?


non, em dans la plupart des logiciels, c'est juste le corps de la
police en cours, chez tex, c'est choisi par le dessinateur, il doit
aussi y avoir des trucs de ce genre dans les tables OT.

AH> Autant dire qu'on en sait rien et que ça
AH> change selon les polices...

justement, c'est l'intérêt ! La fine *dépend* de la police !!


AH> 2) soit du double de la chasse du 0 (zéro), autrement dit une fine serait un
AH> demi-zéro, autrement dit pas grand chose - vu que diviser 0 par deux ça donne
AH> presque rien (on dirait du Raymond Devos, mais je dois à l'honnêté d'informer
AH> les béotiens, les InDesigniens, les TeXiens, que je n'invente rien : cette
AH> absurdité est la valeur _par défaut_ que XP**** propose à ses utilisateurs.)

bon, à part le jeu de mot, ça te fait un quart de cadratin dans les
cas généraux (en particulier avec les polices linotype)

AH> Reste qu'on a besoin d'une fine (valeur à définir par l'utilisateur) ET d'une
AH> micro-fine (pour mettre avant les appels de note par exemple). Pas trop
AH> dilatable, la fine. Juste un tout petit peu. Pas dilatable du tout, la
AH> micro-fine : elle n'est pas faite pour ça.

on a besoin de se fondre ses espaces pour chaque boulot, je pense. En
avoir une tripotée pour écrire une lettre à sa chérie encombre les
menus, Et il y en aura toujours une qui manque dans l'interface si
elle a été conçue une fois pour toute par quelqu'un qui n'a pas les
mêmes idées que toi sur le sujet.

AH> À une époque, toujours extrémiste, tu voulais _en plus_ une fine négative pour
AH> bidouiller des maths : ah ! jeunesse, fougueuse jeunesse, comme tu nous sembles
AH> lointaine.

je l'ai en standard, et quelques autres... (et je peux évidemment m'en
faire autant que je veux !)

>>Mais Indesign doit coller plus près d'unicode, et ces espaces-là sont
>>des caractères dans unicode... Donc probablement définis par une
>>police OT.
>>
AH> On rejoint ici un vieux débat, mais z'enfin : Unicode est là pour nous servir,
AH> et non pas nous pour servir Unicode. Qu'un technocrate de l'ISO, ou de
AH> l'industrie, ou de n'importe où, ait l'idée saugrenue d'introduire dans cette
AH> usine à gaz des « espaces chiffres » est parfaitement possible (s'il ne l'a pas
AH> eu, il l'aura un jour ou l'autre, il en fera un cas d'espèce, un motif de
AH> rupture, l'annonce probable de la fin des temps si le consortium s'y refuse,
AH> etc.)

AH> Qu'on se plie à ce genre de caprices (« On » : les utilisateurs, les
AH> programmeurs, les concepteurs) me paraît insensé.

Ben moi je trouve pas ça idiot : les espaces dans une police sont des
glyphes sans oeil avec une chasse. Si le dessinateur a pris le temps
de définir un glyphe « espace fine » et un autre « feuille de papier à
cigarette » (qu'unicode appelle hair thin à cause des risques de
procès des associations anti-nicotine), je peux bien récupérer cette
chasse comme valeur au repos de ma fine, etc.


 Thierry