Des fontes, une famille
Sous Adobe Photoshop, une famille de fontes au grand complet comme Adobe Myriad Pro apparaît comme une fonte à 40 styles. Sous Microsoft Word 2007, comme 10 fontes à 4 styles. Qu’est-ce qui provoque cela ?
Structure d’une fonte
Dans une fonte Type 1, le nom d’une fonte et sa famille sont stockés dans un dictionnaire public (stockage différent selon la plateforme Mac, Windows ou Unix). Il y a plusieurs informations optionnelles, mais une entrée obligatoire est FontName, souvent constituée par convention en deux parties, le nom de la famille de la fonte et le nom de son style, jointes par un trait d’union, comme ceci par exemple : MyriadPro-Semibold (il s’agit donc de la fonte Myriad Pro Semibold).
Dans une fonte OpenType (toute fonte à extension .ttf ou .otf), l’information de nom et de famille est stockée dans la table name. Assez complexe, chaque enregistrement étant associé à une plate-forme, un codage et une langue (cette dernière association étant, hormis pour les fontes Microsoft, rarement employée). Pour simplifier, on ne retiendra que quelques enregistrements (nameID) principaux :
- l’enregistrement 1, qui est le nom de famille de la fonte ;
- le 2, qui stocke le style de la fonte (le nom de ce style est censé être libre, mais par compatibilité avec les applications GDI – voir plus loin – il est mis en accord avec une entrée de la table
OS/2, soit une limitation à 4 styles définis) ; - le 4, qui réunit le 1 et le 2 pour former le nom complet ;
- le 6, qui contient le nom PostScript de la fonte, pour compatibilité avec les systèmes utilisant de préférence ce nom ;
- le 16 (« Preferred Family », devenu « Typographic Family name » dans la version 1.7 des spécifications), qui stocke le nom de famille (parfois différent du 1, l’enregistrement 16, comme les suivants, n’existait pas à l’origine dans le spécifications TrueType et a été introduit lorsque TrueType a évolué en OpenType) ;
- l’enregistrement 17 (« Preferred Subfamily », devenu « Typographic Subfamily name » dans la version 1.7 des spécifications), qui stocke le style de la fonte (sans contrainte préalable) ;
- le 18 (« Compatible Full Name, Macintosh only »), qui est prévu pour les menus sous Mac OS ;
- le 21 (« WWS Family Name »), qui est encore une entrée pour le nom de famille, introduite par la version 1.6 des spécifications OpenType, destinée au nouveau modèle introduit par l’API dite WWS de Microsoft ;
- et enfin l’enregistrement 22 (« WWS Subfamily Name »), qui est aussi une entrée pour le style de la fonte, suivant le modèle WWS.
GDI, la source du mal
Pourquoi une telle complexité ?
L’essentiel du problème vient de l’API GDI (héritée de Microsoft Windows 3.1 et qui reste la base pour l’immense majorité des applications tournant sous Windows). GDI ne propose que des fontes à 4 styles, toujours les mêmes : regular, gras, italique, gras italique. Pour rendre une fonte comme la Myriad Pro Semibold compatible avec ce système, il faut la faire rentrer, de force forcée, dans ce système rigide à 4 styles. Voici ce que l’on peut observer si on l’ouvre avec FontLab Studio :
Propriété de la fonte Myriad Pro Semibold sous FontLab Studio, première fenêtre.
Propriété de la fonte Myriad Pro Semibold sous FontLab Studio, deuxième fenêtre.
Les applications GDI vont lire l’enregistrement 1 (GDI ignore les enregistrements 16 et suivants, qui n’existaient pas à l’époque de sa création) de la table name (identifié sous FontLab comme « Family Name ») et vont donc voir cette fonte comme étant « Myriad Pro Light », style gras (case cochée « font is bold »). Par contre, une application moderne comme Illustrator, InDesign, Photoshop, ou encore Flash depuis sa version CS4, lira les enregistrements 16 et 17 (notés sous FontLab comme « OpenType-specific names ») et la considérera comme la fonte « Myriad Pro », style « Semibold ».
En répétant les contorsions du premier cas, les quarante styles de la Myriad Pro pourront être vu comme dix familles différentes, à quatre styles chacune. Le second cas étant libre de toute contrainte de ce type, toutes les variantes de Myriad Pro seront bien considérés comme appartenant à une seule famille.
C’est d’ailleurs la totale liberté laissée pour l’enregistrement 17 qui a conduit Microsoft à proposer les enregistrements 21 et 22 : le style indiqué dans l’entrée 22 ne peut être qu’un des styles prévus par l’API WWS, qui reprend les styles prévus par la spécification CSS3. On limite ainsi la créativité mais on s’assure de la compatibilité entre fontes : changer de fontes dans une application ne devrait pas obligatoirement faire perdre le style choisi. Mais pour l’instant, les applications utilisant WWS sont d’importance et de nombre négligeables.
Et ailleurs ?
Les applications tournant sous Mac OS X connaissent différentes variations du problème : Mac OS n’a jamais eu les contraintes de GDI, mais les applications importées de Windows, comme Microsoft Office, l’ont, et donc le système n’est pas totalement unifié dans sa gestion des fontes. Il est de plus bien évident qu’une compatibilité multi-plateforme, spécialement en PAO, ne peut reposer que sur des applications ayant dépassés les contraintes de GDI : on imagine les soucis causés par un document InDesign utilisant la Myriad Pro Semibold sous Mac OS qui n’arriverait pas à la trouver sous Windows faute de la reconnaître comme la Myriad Pro Light, style gras. Heureusement, Adobe, à la différence de Quark pour XPress, a prévu cette compatibilité dès InDesign 1.0 et plus tard pour ses autres produits phares en établissant son menu de fontes à partir des nouvelles entrées de la table name introduites par les spécifications OpenType.
Références (autres que celles citées dans le texte) :
Bug 454514 - implement better style linking of font families under windows