Le moteur textuel sous Mac OS X a été porté vers Core Text, ce qui permet d'améliorer le rendu, et de prendre en charge les polices OTF complexes.
Mac OS X n'est pas le seul concerné par un portage du moteur textuel. Cf. les notes de version de LO :
Mise en page de texte sur Linux (et autres environnements X11) a été portée de librairies ICU dépréciées et non maintenues vers : HarfBuzz (Khaled Hosny, Fridrich Štrba), ce qui fournit une meilleure gestion pour les mises en page OpenType en général et les scripts complexes en particulier, aussi bien qu'une amélioration notable des performances, en particulier pour les polices avec un grand nombre de recherches OpenType.
Tiens, oui, une question : pourquoi ne pas respecter ce qui est sérigraphié sur deux touches d'un clavier français (² tout en haut à gauche, Alt Gr + $ donnant ¤) ? Ça a vraiment fait consensus ?
Nénufar vient de l'arabe. Il s'est toujours écrit ainsi, sauf dans la réforme de 1935 (édition précédente du dictionnaire de l'Académie, la 8e), où, croyant que le mot venait du grec, on l'a écrit nénuphar.
Est-ce que Graphite gère les fonctions pour faire de la belle typographie comme vous dites, et avec quelle interface ?
Je dois dire que cela fait longtemps que je n'ai pas regardé Graphite de près. Dans mon souvenir, Graphite ne redéfinissait pas ce qui existe déjà : les tables GSUB et GPOS en OpenType sont suffisantes, comme Graphite vise plus à être un complément qu'un remplacement (je crois aussi qu'il peut utiliser les tables AAT).
Un des problèmes majeurs de toutes ces belles fonctions est qu'il est impossible de les échanger entre applications.
Vieux problème ! On en parle justement en ce moment sur la liste OpenType. Un des participants écrivait : «The major application vendors have failed in producing an industry-wide format for storing styled text that would allow the user to preserve OpenType Layout formatting across systems or applications. This could have done by means of extending the RTF format and publishing these extensions, as well as preparing a suitable extension of the CSS format. And this should have been done early on, around 2000-2002. I deeply regret that the OpenType "fathers" failed to do that on time, though I bear hope that this still can be done in future.»
Il existe bel et bien un moteur de rendu des scripts complexes libre et multiplateforme : Graphite.
C'est même une extension supplémentaire (et complémentaire parfois) du format SFNT (le format des fontes OpenType). C'est effectivement plus dans une logique «libre» de toute façon : dans les implémentations actuelles d'OpenType, on est très dépendant de la prise en charge de l'application.
Dans un logiciel Adobe (InDesign par exemple), si la version que vous avez ne prend pas en charge telle ou telle fonction OpenType, il n'y a pas grand chose à faire. Pire encore, si on souhaite employer une autre écriture que celles prises en charge. Il faut attendre qu'Adobe daigne ajouter de nouvelles fonctions. En AAT, on est un peu plus libre : l'interface vous montre les fonctions réellement disponibles dans la fonte, pas une simple sélection prédéterminée. Graphite (enfin, la dernière fois que j'ai lu les specs, ce qui remonte déjà à un certain temps) propose d'aller au bout de cette démarche pour garantir qu'une application compatible Graphite peut faire fonctionner n'importe quelle fonte Graphite, même celles développées pour une écriture dont le développeur de l'appli n'aurait jamais entendu parler.
On peut donc utiliser les ligatures standard ('liga'), les ligatures selon le contexte ('clig'), les compositions/décompositions de caractères ('ccmp'), les caractères diacritiques positionés à l'aide d'ancres ('mark', 'mkmk') et comme avant le crénager ('kern').
Oui, bien sûr. J'y avais pensé (MS Uniscribe fait la même chose, d'ailleurs), mais tout ça c'est essentiellement pour les langues «exotiques» à écriture latine (vietnamien, langues africaines...). C'est fait dans la même perspective que pour les écritures complexes : la prise en charge linguistique. Mais rien pour la belle typographie... Pas assez de graphistes dans le Libre ?
De plus il faudrait une interface commune pour y accéder dans les dialogues de sélection de police de caractère.
Que veux-tu dire précisément ? Uniscribe sous windows sait très bien gérer les écritures complexes. Il ne me semble pas qu'OS X ait des déficiences là-dessus non plus (via AAT et pas OpenType certes).
Justement je parlais des écritures dites «simples» -- en fait complexes en bonne typographie : petites capitales, chiffres elzéviriens, ligatures, &c.
Adobe a un processeur OpenType pour l'écriture latine (qu'il est en train d'étendre aux écritures complexes), Apple converti à la volée les fonctions OpenType latines en fonctions AAT (enfin, celles qui ne correspondent pas à un automate fini en AAT) et Microsoft aura un nouveau processeur OpenType dans WPF qui fera tout ce que fait déjà Uniscribe (les écritures complexes) plus les écritures simples.
Il n'y a rien d'équivalent en libre, alors que des applis comme Scribus et Inkscape en bénéficieraient grandement.
Cela devrait être comblé par le projet harfbuzz visant à unifier les moteurs de rendu de Qt (qui l'utilisera à partir de la version 4.2) et de GTK+ (qui l'utilise dans sa version CVS) et rattrapera le retard sur les moteurs Windows (uniscribe) et OS X AAT.
De ce que j'ai lu et de ce que Behdad Esfahbod m'avait expliqué, je n'ai pas retenu que nous en soyons là. HarfBuzz est une réorganisation du code qui était dans Pango, pour en faire un projet séparé et utilisable par Qt. Pour Pango, c'est déjà chose faite avec Pango 1.13.0 (unstable) http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg(...)
Bref, c'est bien pour Qt dont la prise en charge d'OpenType était réputée moins bonne, et à terme c'est bon pour tout le monde, mais ça ne change pas grand chose dans l'immédiat. Pango, comme ICU (utilisé par OpenOffice), fourni une prise en charge d'OpenType pour les écritures dites complexes, pas les «simples» (latin, cyrillique, grec). Rien à voir donc avec ce que fournissent actuellement Apple et Adobe, et bientôt Microsoft avec WPF.
OpenType ce n'est pas seulement Microsoft, c'est aussi Apple (qui détient malheureusement des brevets utiles dessus)
OpenType c'est Microsoft et Adobe. Les brevets d'Apple c'est pour les contours TrueType. Ça se recoupe mais ce n'est pas la même chose.
# Moteur textuel
Posté par Thomas Linard (site web personnel) . En réponse à la dépêche LibreOffice 4.1 et Apache OpenOffice 4.0 sont de sortie. Évalué à 10.
Mac OS X n'est pas le seul concerné par un portage du moteur textuel. Cf. les notes de version de LO :
[^] # Re: Nouveau clavier intégré dans le CVS freedesktop
Posté par Thomas Linard (site web personnel) . En réponse à la dépêche [RFC] Évolution du clavier « fr-latin9 ». Évalué à 2.
[^] # Re: exemples
Posté par Thomas Linard (site web personnel) . En réponse à la dépêche OpenOffice.org prend désormais en compte la nouvelle orthographe française. Évalué à 3.
[^] # Re: HarfBuzz
Posté par Thomas Linard (site web personnel) . En réponse à la dépêche DejaVu, la famille de fontes libres de référence. Évalué à 0.
Je dois dire que cela fait longtemps que je n'ai pas regardé Graphite de près. Dans mon souvenir, Graphite ne redéfinissait pas ce qui existe déjà : les tables GSUB et GPOS en OpenType sont suffisantes, comme Graphite vise plus à être un complément qu'un remplacement (je crois aussi qu'il peut utiliser les tables AAT).
Vieux problème ! On en parle justement en ce moment sur la liste OpenType. Un des participants écrivait : «The major application vendors have failed in producing an industry-wide format for storing styled text that would allow the user to preserve OpenType Layout formatting across systems or applications. This could have done by means of extending the RTF format and publishing these extensions, as well as preparing a suitable extension of the CSS format. And this should have been done early on, around 2000-2002. I deeply regret that the OpenType "fathers" failed to do that on time, though I bear hope that this still can be done in future.»
[^] # Re: HarfBuzz
Posté par Thomas Linard (site web personnel) . En réponse à la dépêche DejaVu, la famille de fontes libres de référence. Évalué à 3.
C'est même une extension supplémentaire (et complémentaire parfois) du format SFNT (le format des fontes OpenType). C'est effectivement plus dans une logique «libre» de toute façon : dans les implémentations actuelles d'OpenType, on est très dépendant de la prise en charge de l'application.
Dans un logiciel Adobe (InDesign par exemple), si la version que vous avez ne prend pas en charge telle ou telle fonction OpenType, il n'y a pas grand chose à faire. Pire encore, si on souhaite employer une autre écriture que celles prises en charge. Il faut attendre qu'Adobe daigne ajouter de nouvelles fonctions. En AAT, on est un peu plus libre : l'interface vous montre les fonctions réellement disponibles dans la fonte, pas une simple sélection prédéterminée. Graphite (enfin, la dernière fois que j'ai lu les specs, ce qui remonte déjà à un certain temps) propose d'aller au bout de cette démarche pour garantir qu'une application compatible Graphite peut faire fonctionner n'importe quelle fonte Graphite, même celles développées pour une écriture dont le développeur de l'appli n'aurait jamais entendu parler.
[^] # Re: HarfBuzz
Posté par Thomas Linard (site web personnel) . En réponse à la dépêche DejaVu, la famille de fontes libres de référence. Évalué à 1.
Oui, bien sûr. J'y avais pensé (MS Uniscribe fait la même chose, d'ailleurs), mais tout ça c'est essentiellement pour les langues «exotiques» à écriture latine (vietnamien, langues africaines...). C'est fait dans la même perspective que pour les écritures complexes : la prise en charge linguistique. Mais rien pour la belle typographie... Pas assez de graphistes dans le Libre ?
Exactement.
[^] # Re: HarfBuzz
Posté par Thomas Linard (site web personnel) . En réponse à la dépêche DejaVu, la famille de fontes libres de référence. Évalué à 2.
Justement je parlais des écritures dites «simples» -- en fait complexes en bonne typographie : petites capitales, chiffres elzéviriens, ligatures, &c.
Adobe a un processeur OpenType pour l'écriture latine (qu'il est en train d'étendre aux écritures complexes), Apple converti à la volée les fonctions OpenType latines en fonctions AAT (enfin, celles qui ne correspondent pas à un automate fini en AAT) et Microsoft aura un nouveau processeur OpenType dans WPF qui fera tout ce que fait déjà Uniscribe (les écritures complexes) plus les écritures simples.
Il n'y a rien d'équivalent en libre, alors que des applis comme Scribus et Inkscape en bénéficieraient grandement.
# HarfBuzz
Posté par Thomas Linard (site web personnel) . En réponse à la dépêche DejaVu, la famille de fontes libres de référence. Évalué à 5.
De ce que j'ai lu et de ce que Behdad Esfahbod m'avait expliqué, je n'ai pas retenu que nous en soyons là. HarfBuzz est une réorganisation du code qui était dans Pango, pour en faire un projet séparé et utilisable par Qt. Pour Pango, c'est déjà chose faite avec Pango 1.13.0 (unstable) http://mail.gnome.org/archives/gtk-devel-list/2006-April/msg(...)
Bref, c'est bien pour Qt dont la prise en charge d'OpenType était réputée moins bonne, et à terme c'est bon pour tout le monde, mais ça ne change pas grand chose dans l'immédiat. Pango, comme ICU (utilisé par OpenOffice), fourni une prise en charge d'OpenType pour les écritures dites complexes, pas les «simples» (latin, cyrillique, grec). Rien à voir donc avec ce que fournissent actuellement Apple et Adobe, et bientôt Microsoft avec WPF.
OpenType c'est Microsoft et Adobe. Les brevets d'Apple c'est pour les contours TrueType. Ça se recoupe mais ce n'est pas la même chose.
[^] # Re: Polices OpenType
Posté par Thomas Linard (site web personnel) . En réponse à la dépêche Retour d'Adobe sur les plates-formes Linux ?. Évalué à 2.
# Polices OpenType
Posté par Thomas Linard (site web personnel) . En réponse à la dépêche Retour d'Adobe sur les plates-formes Linux ?. Évalué à 3.
Très bonne nouvelle pour la typographie sous Linux, même si certaines applications renâclent devant ces polices *.otf (cf. http://www.openoffice.org/issues/show_bug.cgi?id=16032(...) ).