Re: OpenType, version 2002-01-10

[Patrick Andries <pandries AT iti.qc.ca>]

Thierry Bouche wrote:
> Patrick Andries a écrit :
> Il n'y a aucune distinction linguistique entre oe et ae, bon sang de
> bonsoir !
>   
On parlait de diphtongue, il s'agit de digrammes et non diphtongues.
> La seule différence entre ces caractères est due aux cafouillages de
> l'ISO, que je sache. Je veux bien que, quand on discute avec l'iso, on
> sorte ce concept de polygramme de poids deux, mais pas entre nous ! œ
> _est_ un graphème du français !!
>
>     
Le mot clé est "en français". En français, le "ae" [comme le oe] n'est pas
récité dans l'alphabet et classé vers la fin de l'alphabet dans les dictionnaires
ou les répertoires, contrairement à d'autres langues (scandinaves) où il
est une lettre à part entière. Peut-être faut-il distinguer des degrés de
graphèmes (les lettres de l'alphabet sur lesquelles on trie et qu'on apprend
à l'école par rapport aux oe et ae soudés).  
> je ne comprends pas trop la remarque : l'idée est que, en sélectionnant
> un caractère et en lui appliquant l'option "superscripts", on appelle
> cette feature opentype.L'appel pourrait très bien être lui-même sauvé
> dans le fichier sous forme d'une balise qualitative qu'un moteur
> d'affichage peut interpréter comme un truc opentype, ou simuler façon
> word, selon la police employée et ses capacités typo.
>       
Je comprends, je dis que cette fonctionnalité Opentype n'est peut-être pas
très productive (pas la peine d'avoir une nouvelle table).
      
Le logiciel d'édition peut bien sûr stocker cette information (<suscrit>2<suscrit>)
et lors du rendu passer par le processus mentionné : passage à ² si le code
existe en Unicode puis par cmap au glyphe (la majorité des suscrits communs
sont codés ainsi) ou rendre la châine de manière algorithmique pour des suites
non codées dans Unicode et plus générales  (<suscrit>¶ Une petite phrase
en exposant §<suscrit>). Ces suites non codées dans Unicode ont peu
de chance d'être dans des fontes, d'où le manque de productivité de ce type
de fonctionnalité (de table) potentielle d'Opentype.  
>
> InDesign manipule les glyphes d'une police en utilisant leurs noms
> plutôt qu'un vecteur de codage et  de simples numéros.Acrobat aussi,
> d'ailleurs, ce qui permet de chercher "efficace" et de le trouver, même
> si ffi est pris dans une police expert ; ça lui permet également de
> trouver ffi dans Palatino linotype OT, qui contient ce glyphe mais ne
> lui affecte pas son codage Unicode, ou les petites caps, etc. De la
> sorte, il est incapable de substituer le glyphe ffi à la saisie f+f+i si
> on utilise une police type 1 standard (il se contentera de remplacer f+i
> par fi), mais si la police contient les glyphes qu'il faut, avec les
> noms attendus par indesign (il y a un système de noms de glyphes
> développé par adobe, qui permet de savoir même dans des cas assez
> limites qu'un glyphe est conçu comme ligature de deux autres), alors la
> substitution se fera
> , indépendamment du format.
>           
Oui, je vois et j'ai déjà vu ça dans les fichiers. Si ces noms sont non standardisés
cela empêche l'échange des fichiers ou leur interprétation (recherche de
mots), or il existe déjà une norme qui code les caractères (et non les glyphes)
: Unicode. Il permet l'échange des données même si on n'a pas la police utilisée
ou on ne comprend pas le balisage stylistique du document. Vouloir exploiter
(rechercher une chaîne de caractères ou trier le fichier, par exemple) des
fichiers dont le codage serait basé sur les glyphes plutôt que leurs graphèmes
augmenterait de manière importante la complexité de tous les algorithmes
concernés (il faut alors traiter toutes les combinaisons de variantes stylistiques).
          
Mais la modification des noms de glyphes, si je peux me permettre, c'est
de la cuisine interne. Pour l'utilisateur, je pense que le nom des glyphes
est relativement sans importance : c'est l'effet qui compte et avec une police
donnée,  ses tables de substitution et le balisage adéquat (ligature jusqu'à
3 lettres, choisir telle variante à l'aide d'une palette) on peut obtenir
le même résultat. Le logiciel pourra alors, sans bidouillage, substituer
ffi à f+f+i à la saisie ou lors d'un simple changement de style (police)
si la ligature est présente dans la police choisie. Si par la suite, la police
(ou le style) est changée,  les ligatures ffi  pourront être déligaturées
automatiquement (en f+fi ou f+f+i, selon les options de ligature et la disponibilité
des glyphes). C'est, selon moi, un procédé nettement plus puissant et généralisable
(les conjointes dévanâgaries ou les ligatures arabes).
>
> > Je ne pense pas que PS Type 1 soit aussi puissant qu'OpenType en matière
> > de gestion des substitutions (variantes de style (esperluettes),
> > variantes contextuelles (syriaque, dévanâgarî) ou des ligatures).
> >                 
>
> Jamais dit ça !
>                 
Je ne vous accuse pas, j'ai bien dit ne pas avoir suivi tout le fil. 
> Soit dit en passant, il eût été fort aisé de faire OT en type 1 :
> étendre le format pfm et utiliser des polices (PFB) CID ; l'avancée OT
> par rapport à T1 se limite à des métriques enrichies de diverses tables,
> ce qu'on aurait très bien pu mettre dans le PFM. (et au format plus
> compact des type 2, mais rien n'empêche de mettre une type 2 dans un PFB
> !)
>                   
Pourquoi ne pas considérer que OT est un descendant de PS Type 1 et s'en
accommoder ?
                  
Patrick A.