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

[Alain Hurtig <alain@xxxxxxxxxxxxxx>]

[Espace invaraibale après un tiret de dialogue]
>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)
>
Exact, mais comme je le notais, ça dépend énormément de la structure du texte et
du travail qu'on a à y faire. Je sais des cas où je serais bien embêté d'avoir
une tabulation en plus et en début de ligne.

>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 :
>
Ce qui serait chic, ce serait de pouvoir définir dans les feuilles de style
quelque chose comme : « Le paragraphe commence par tels signes de telle ou
telle police », en précisant le nombre de signes. ID sait faire ça, je crois
(mais pas sûr qu'ID gère cette histoire d'espace invariable). Je présume qu'en
TeX ça ne pose pas de problèmes particulier.

Parce qu'il n'y a pas que la saisie, il y a aussi l'importation de textes saisis
ailleurs (typiquement dans Word), en dépit du bon sens et avec n'importes
quelles feuilles du style (lesquelles sont généralement imposées par Word sans
que l'utilisateur lambda s'en rende vraiment compte).

>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.
>
C'est exactement ça que je voulais dire. Ce n'est pas automatique ?

>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 est vrai que je pensais à l'utilisation des fines et à leur
rétrécissement/élargissement. Mais fines ou espaces-mots insécables,
l'élargissement excessif donne des résultats catastrophiques (et le
rétrécissement trop fort des résultats simplement disgracieux) par exemple dans
des colonnes étroites. Pour faire rentrer le texte, le logicie joue sur les
intermots, lesquels sont différents de ligne en ligne - et si une espace qui
suit un guillemet ouvrant est d'une taille nettement différente de l'espace qui
précède le guillemet fermant à la ligne d'en dessous ou même trois lignes plus
loin, ça choque terriblement l'oeil.0

>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).
>
En fait oui ,-))). Ce qui est amusant, c'est qu'on reprend ici exactement les
termes du débat sur K2, avec exactement les mêmes arguments.

Le wysiwig n'est en rien un carcan, c'est simplement une façon de travailler qui
est différente de la tienne - parfois plus rapide et plus précise, parfois non.
Entre autres, c'est du montage papier, mais sur écran - ça concerne peu le
livre mais tout le monde ne fait pas du livre. Pour la gestion du flot de
texte, il permet de voir avant impression ce qui va et ce qui ne va pas (faut
un oeil un peu exercé, mais ça s'apprend).

Il suffirait donc de disposer de la boîte en question, qui permette de définir
les espaces dont on a besoin. Y associer un éditeur de texte brut (pas vraiment
wisiwig, pour le coup) affichant tout ce qui est invisible sous forme de balises
permettrait à ceux qui ont le temps et le goût de faire ça d'aller bidouiller au
cas par cas si sur une ligne quelque chose ne va pas.

>De façon
>générale, ce genre de possibilité dans les logiciels de PAO pourrait
>faire exploser le niveau de qualité possible.
>
Ben oui. On a parfois le sentiment que les éditeurs des logiciels de PAO ne
savent pas lire... (ou se contrefichent du texte).

>Donc, tex a d'abord un ensemble de dimensions dans lesquelles
>l'utilisateur peut piocher pour définir des espaces
>
XPress et ID font ça aussi, pour définir à peu près tout - XPress connaît même
un pouce millimétrique et des agates, je me demande bien ce que c'est. En
pratique, tout le monde (sur XPress, je veux dire) travaille avec le systéme
métrique décimal pour chaque objet, et avec les points Postscript pour les
polices.

>Ensuite, tex fournit à ses utilisateurs
>des dimensions extrêmement pratiques pour créer des blancs qui
>survivent aux changements de corps ou de police
>
Et quid de la fine invariable de 1 pt, ou de 1,5 pt (indépendante de la police
et de sa force de 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).
>
Je suis un peu lent, sans doute, mais je ne comprend pas à quoi ça sert
vraiment.

> C'est comme ça
>qu'on implémenterait l'« espace sans alinéa » d'ID.
>
Note qu'on a eu deux explications à propos de cet espace sans alinéas d'ID, qui
m'ont parues parfaitement contradictoires (car ne décrivant pas la même chose
!)

>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
>
Ensuite de tout ça, XP et ID font exactement la même chose, y compris les
modifications de valeurs optimales et les paramètres d'élasticité en
pourcentage.

>l'espace semijustifiante insécable pour les guillemets français est
>celle-ci :
>
Là, avantage à TeX, de toute évidence, puisqu'il permet de fondre ses propres
espaces, non prévues au départ dans la police.

Je présume qu'on peut même fondre la micro-fine que je réclame depuis si
longtemps, avec pas d'élasticité du tout, et même lui demander de la mettre
gentiment avant les appels de note sans que l'opérateur ait besoin de s'en
préoccuper (une autre méthode est de crêner un chouia avant les appels, en
pratique ça revient à duistribuer un peu de blanc).

>\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,
>
Non, c'est très compréhensible. Je m'interroge simplement sur la plausibilité de
la création d'une telle macro par l'opérateur moyen. Je suppose qu'en pratique
et dans la production industrielle, ça impose une sorte de division du travail
que la PAO avait presqu'abolie : d'un côté l'ingénieur créé des macros, de
l'autre l'opérateur les introduit (sans forcément bieen savoir ce qu'il fait ni
à quoi ça sert).

>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.
>
S'il t'est doux, mon babil, ça n'a pas d'importance que tu ne le comprennes pas.
Sa douceur seule m'importe ;-).

>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.
>
Interlettrage positif et surtout négatif. Variation de l'angle des obliques.
Soulignement paramétrable. Décision sur la valeur de la fine. La cour est déjà
assez pleine pour ne pas évoquer en plus les effets graphiques
semi-automatiques permis sur le texte par des logiciels comme Illustrator et
Photoshop, mais je vais en rajouter une : jusqu'au mot « parangonage » qui a
changé de sens entre le plomb et les électrons.

Oui, au début le moteur de composition modélisait le travail à l'ancienne (plus
probablement la photocompo que le plomb, d'ailleurs). Puis il s'en est
affranchi.

>Donc, non, le paradigme est le même, sauf qu'on a une
>flexibilité supplémentaire due à la dématérialisation des caractères,
>
Bon, c'est de la haute philosophie, mais pour moi le quantitatif s'est ici
transformé en qualitatif. pas pour toi, ce qui rend ce débat-là assez vain : on
ne se convaincra pas l'un l'autre.

>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).
>
Ça prouve simplement que tu n'es jamais rentré dans un atelier-plomb. S'imaginer
que la communication avec un typo est plus facile qu'avec une interface même mal
conçue relève d'un merveilleux fantasme (s'imaginer que le typo _comprend_ ce
qu'on lui demande, surtout lorsqu'il n'a pas envie de comprendre ou bien de
fairee le travail, relève d'un plaisant mais parfait délire ;-)))

>(due à des interfaces conçues pour des mal comprenants informatiques
>pas forcément au courant de la notion de copie préparée).
>
Je dirais plutôt : « conçue PAR des malcomprenants ».

[Valeur du cadratin et de l'espaace]
>ben tu traduis donc 1 pt par em/10 et hop
>(ou em/9 si t'es Tschicholdien)
[...]
>Non, non : ici M = em = cadratin. (qui n'est *pas* la chasse du M,
>combien de fois ai-je lu cette erreur !)
>
On la lit partout, du coup ça devient une sorte de standard... Cadratin = force
de corps est plus précis, je pense - mais à l'inconvénient d'être
disproportionné avec certaines polices - celles qui ont un tout oeil en
particulier).

>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 !!
>
De la police, certes, et de plein d'autres choses : de la force de corps, de la
largeur de justification, de l'interlignage, de la nature du texte (longueur
des mots, emploi fréquent ou pas de fines, etc.), du gris qu'on veut générer.

J'ai ainsi souvenir d'un curieux petit ouvrage où les fine étaient parfois plus
large que les espaces normales (en tout cas ces dernières pouvaient se
contracter bien plus que les fines) : c'était destiné à faire un peu peur au
lecteur et à donner un aspect « sale » au bouquin, maculant presque les doigts
: ça fonctionnait, ma foi, plutôt bien...

>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
>
>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)
>
Je ne me relis pas toujours c'est vrai, mais j'ai oublié depuis combien de temps
je n'avais pas proféré : « C'est un cas général, en particulier dans un certain
cas » ;-).

En pratique, personne ne sait trop bien si la police qu'il utilise est Linotype
ou pas... Quand aux polices à chiffres elzéviriens, évidemment, le cas général
leur est vraiment trop particulier. Non ?

>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.
>
Rien à redire à ça.

[Espaces définies dans Unicode et OT]
>Ben moi je trouve pas ça idiot : les espaces dans une police sont des
>glyphes sans oeil avec une chasse.
>
Je ne dis pas qu'il ne faut pas les utiliser (c'est d'ailleurs rendu
indispensable pour l'archivage, XML et le reste). Je dis qu'on ne peut pas être
sous la dictature de valeurs probablement inutilisables même en standard. Fines
et micro-fines parce que leurs valeurs dépendant du travail à faire, espaces
mots parce qu'elles sont en général trop larges, et s'élargissent de plus en
plus (c'est la mode).

Mais puisque tu dis toi-même fondre tes propres espaces, le problème se règle
tout seul, je pense.