Re: [typo] Unicode et autres - police expert

[Thierry Bouche <thierry.bouche@xxxxxxxxxxxxxxx>]

Le jeudi 13 février 2003, à 23:21:19, Thomas Linard écrivit :

TL> Dans mon souvenir, Unicode a pour propos de :
TL> 1. réaliser un codage universel distinguant caractère et glyphe (le fond
TL> et la forme, disons) ;

justement non, pas du tout, erreur totale : je viens de comprendre à
la lecture du très intéressant article de yannis et de la très
édifiante interview de Whistler (il parle bien le français, ce type !
à part quelques anglicismes terribles comme « cette implication
précède [...] par plus d'un an. ») que le caractère et le glyphe sont
indiscernables, et concernent tous les deux la forme. En reprenant
l'exemple allemand de yannis, si unicode codait le fond, il donnerait
un moyen de discerner Wachs{}tube de Wach{}stube qui sont deux mots
distincts aux propriétés typographiques et linguistiques différentes.
Or il ne donne que le moyen d'échanger entre deux ordinateurs _une_
forme imprimée de chacun de ces mots, dépouillée de son encre :
unicode est fait pour transporter un texte RTF donné, et être bien sûr
qu'il s'imprimera à l'identique des deux côtés du tuyau. il ne sert
donc qu'à échanger une _forme_. Il m'a fallu très longtemps pour
comprendre ça, mais ça semble tellement évident en y repensant que je
me trouve bien bête !

Quand on voit whistler expliquer que le nom unicode des caractères n'a
pas d'autre importance que d'être unique, qu'il y a toujours le nº
pour le définir, et pourquoi pas le glyphe canonique, on voit que ça
craint gentiment, non ?

échanger ou stocker le fond, ce serait être capable de modéliser un
ensemble de propriétés linguistiques voire sémantiques d'un énoncé en
langue naturelle, et d'en déduire différents « rendus » : écrits,
parlés, langage des signes, etc. Quand on pense au paradigme HTML
(XML) source-texte brut/typo-texte enrichi, on a tendance à croire que
le monde des caractères est effectivement celui qui permet
d'abstraire la forme d'une publication, pour pouvoir permettre
les sorties multisupport tant à la mode. Mais non, le texte brut
unicode ne contient pas de sens (ni plus ni moins de sens que sa
version formatée, en fait, et plutôt moins puisqu'il renonce à garder
des nuances comme les supérieures ou les petites caps, sans aller
jusqu'à supprimer les capitales), et il est utile de se souvenir que
chaque fois qu'il est question de « rendu » dans ce monde-là, c'est
d'impression qu'il s'agit. Dans ces conditions, le dédain pour la typo
est plutôt mal venu, je trouve.

La seule utilité d'unicode, ce serait de pouvoir échanger de la copie
entre un bureau éditorial de New York et son staff technique de Kuala
Lumpur, on se demande pourquoi il n'y a pas les signes de
préparation de copie et/ou de correction !

La théorie selon laquelle <abr>Canton</abr> est la bonne façon de
coder C^on est au mieux une douce plaisanterie.

TL> 2. permettre la transition depuis un maximum de codages propriétaires,
TL> même s'ils ne respectent pas le point 1.

oui, mais l'exemple de yannis prouve qu'un caractère de l'autre côté
du Rhin peut ne pas en être un de ce côté-ci, ce qui est somme tout
fâcheux. Le s long est dans unicode par compatibilité avec Dfr, donc
déconseillé : dommage !

En fait, on peut résumer 1 et 2 de la façon suivante : il faut qu'un
RTF fabriqué dans une version nationale de windows 3.1 puisse
s'imprimer à l'identique sous win 2000 après conversion en unicode.
Pour ceci, il faut que les appels à wingdings, MT extra, Appolo Expert
ou autres soient interprétés comme des requêtes à un codage que l'on
peut remapper en unicode. le problème étant que ces mentions de
codages ne sont pas présentes dans le RTF, donc en fait, rien de tout
ceci ne sert !


-- 
Cordialement,
 Thierry