Les nouvelles versions sortent à un rythme régulier d'une par mois. Une nouvelle mouture est sortie le 14 mai 2006 apportant un lot important de nouveautés : amélioration des algorithmes d'optimisation (hinting), ajout de nouveaux caractères (symboles mathématiques, combinaisons Braille, etc.). Vous êtes invités à la tester et à rapporter les éventuels problèmes. Si la conception de nouveaux caractères ou l'optimisation de ceux existant vous intéressent, l'équipe de DejaVu accueille les nouveaux dans la bonne humeur et les guidera dans leurs premiers pas (et en français si besoin est). À bientôt ! À l'origine de DejaVu se trouve la diffusion sous licence libre de la famille Bitstream Vera. Celle-ci rencontra un succès immédiat mais n'étant plus développée et ne couvrant guère plus du latin-9 le besoin d'extension s'est fait jour et de nombreux projets sont apparus, sans coordination. Le projet DejaVu lancé par Štěpán Roh a rapidement absorbé totalement ou partiellement plusieurs projets et son mode de développement collaboratif a attiré de nouveaux contributeurs. Aujourd'hui, DejaVu possède désormais un wiki, une liste de diffusion, un canal IRC et a été un des précurseurs de l'utilisation du logiciel Subversion sur sourceforge.
L'objectif actuel du projet est de constituer une famille de fontes homogène, de qualité professionnelle et ayant une couverture unicode aussi importante que possible.
* Dessin homogène : DejaVu se décline en familles sans empattements (DejaVu Sans), avec (DejaVu Serif) et à chasse fixe (DejaVu Mono Sans). Les graisses utilisées sont « normal » et « gras ». Il existe de même une version « italique ».
* Qualité professionnelle : DejaVu gère le crénage et un effort particulier est mis sur les algorithmes d'optimisation afin d'obtenir un affichage à l'écran aussi fin et net que possible.
* Couverture unicode importante : la variante la plus complète est actuellement DejaVu Sans qui contient plus de 3 300 glyphes couvrant totalement pas moins de 136 langues ainsi que les plans (liste non exhaustive) : latin (basique, supplément latin-1, latin étendu A, B et additionnel), les symboles de l'alphabet phonétique international (partiel), le grec, le cyrillique, l'arménien, l'arabe (partiel), les symboles monétaires (partiel), les formes numérales, les flèches (partiel), les opérateurs mathématiques (partiel), les éléments bloc, les formes géométriques, les dingbats, les combinaisons Braille, etc.
L'utilisation d'une fonte de haute qualité est un élément important lors de la migration d'utilisateurs vers un système libre. Le plein potentiel de DejaVu ne peut malheureusement pas encore être pleinement exploité sur les plate-formes libres à cause du manque de support des spécifications OpenType (variantes stylistiques selon la langue, etc.). 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. Cela ne doit pas ralentir les progrès de DejaVu et de nombreux développements sont d'ores et déjà possibles. Pour cela le projet accueille volontiers de nouveaux contributeurs, même débutants (la quasi totalité des développeurs actuels n'avait aucune expérience en typographie il y a peu). Parmi les travaux importants prioritaires sont la qualité et la complétude unicode.
*Qualité : les algorithmes d'optimisation (communément appelés instructions) sont un élément important dans la qualité d'une fonte à l'écran. En effet sans eux un glyphe aura tendance à paraître naturellement flou. Ces instructions permettent de placer des points importants d'un contour à des valeurs entières de pixels. La programmation utilise un langage propre qui peut s'assimiler à un langage d'assemblage
*Complétude : tout caractère présent dans la norme unicode est susceptible d'être intégré dans DejaVu à la condition qu'il respecte le style ainsi que la métrique.
Cela n'empêche pas un travail plus expérimental qui ne pourra être pleinement exploité qu'une fois harfbuzz pleinement fonctionnel, comme le développement d'une graisse « extra-light » on encore d'une version condensée ayant une chasse de seulement 90%.
Alors que vous soyez déjà un utilisateur quasi-professionnel de Fontforge ou un débutant total, que vous soyez un artiste ou un nostalgique des langages d'assemblage, n'hésitez pas à nous rejoindre ! À bientôt !
L'équipe de développement de DejaVu
Aller plus loin
- Le Wiki du projet DejaVu (136 clics)
- Liste des nouveautés (36 clics)
- Téléchargement de la dernière version (225 clics)
- Couverture unicode (68 clics)
- Article Wikipédia sur le crénage (17 clics)
- Tutoriel pour la construction d'algorithmes d'optimisation (22 clics)
# Merci pour cette dépèche
Posté par Raphaël G. (site web personnel) . Évalué à 6.
Sinon j'avais testé avec succès cette police pour ses fonction unicode et c'est un vrai bonheur (notamment l'affichage du japonais dans les pages sans avoir besoin de trifouiller...)
En tout cas c'est très agréable d'avoir une telle police, reste quand même pas mal de boulot pour ajouter un style "fantaisie"
[^] # Re: Merci pour cette dépèche
Posté par med . Évalué à 6.
[^] # Re: Merci pour cette dépèche
Posté par viridis (site web personnel) . Évalué à 9.
J'étais loin d'imaginer le travail que cela représente.
[^] # Re: Merci pour cette dépèche
Posté par Taku . Évalué à 6.
Une ville sans shérif c'est toujours un gros bordel.
Non plus sérieusement merci pour la dépèche, je pense que moi aussi je serais mort sans connaitre la signification de serif sans cette dernière. Donc merci sincèrement.
# TTF ?
Posté par Gaétan RYCKEBOER . Évalué à -2.
Je n'ai rien contre le TTF, pour l'utilisation courante des secrétaires en mal de grafftiis papiers, mais ce serait agréable d'avoir l'intégralité des informations d'origine, ligatures, et autres "gadgets" qui n'en sont plus lors d'une utilisation professionnelle de ces polices...
[^] # Re: TTF ?
Posté par med . Évalué à 10.
[^] # Re: TTF ?
Posté par Gaétan RYCKEBOER . Évalué à 1.
Le TTF est un format bidon, inventé il y a quelques temps pour marcher sur les pieds d'Adobe. Intéressant pour les rendus sur écran, mais de très mauvaise qualité à haute définition.
Je vais jeter un oeil à ce qui en a été fait avec OpenType.
# Utilisation dans Latex/DocBook.
Posté par Bertrand Jacquin (site web personnel) . Évalué à 3.
Je ne connais pas trop tout ca, mais est-ce qu'un support XFT est disponible ?
D'ailleurs a ce sujet, je n'ai jamais su comment lister toutes les polices dispo sur ma distrib, savoir dans quel fichier ca se situe. Meme chose pour Latex, X, XFT, etc ..
C'est un gros problème a mon avis dans les Unix et Linux, c'est la croix et la banière je trouve.
[^] # Re: Utilisation dans Latex/DocBook.
Posté par med . Évalué à 2.
Pour lister les fontes installées, la commande de fontconfig fc-list devrait faire ce que tu désires je pense.
[^] # Re: Utilisation dans Latex/DocBook.
Posté par Anonyme . Évalué à 1.
[^] # Re: Utilisation dans Latex/DocBook.
Posté par Xavier Teyssier (site web personnel) . Évalué à 7.
[^] # Re: Utilisation dans Latex/DocBook.
Posté par reno . Évalué à 3.
[^] # Re: Utilisation dans Latex/DocBook.
Posté par Anonyme . Évalué à 1.
On peut s'en faire une idée ici : http://fr.wikipedia.org/wiki/Tifinagh
[^] # Re: Utilisation dans Latex/DocBook.
Posté par med . Évalué à 6.
J'en profite pour lancer un appel à tous les lecteurs natifs de langues non latines, s'ils peuvent avoir un regard critique sur les glyphes de DejaVu et nous communiquer les remarques. Il est parfois difficile de noter les imperfections en n'étant pas natif. En particulier en ce moment pas mal de travail est encore nécessaire sur l'arménien ainsi que sur l'arabe. Donc surtout n'hésitez vraiment pas à nous donner votre avis.
Finalement, pour visualiser les glyphes qui sont dans DejaVu, je vous conseille l'utilisation de gucharmap, de préférence en version au moins 1.6 (pour avoir le support unicode 4.1). Cela indique le nom de la fonte et cela permet donc de repérer aisément les substitutions effectuées par fontconfig.
[^] # Re: Utilisation dans Latex/DocBook.
Posté par Anonyme . Évalué à 2.
Sinon il existe au moins deux fonderies qui contiennent cet alphabet *: les polices Hapax (Hapax Berbère, Hapax Touareg) et la police MPH 2B Damase (jolie, et couvre beaucoup d'alphabets). Toutes deux sont compatibles unicode.
La difficulté principale est qu'il existe plusieurs versions de cet alphabet.
* Il existe d'autres polices, mais celles que j'ai vu associent les lettres à l'équivalent phonétique occidental ("Z" pour Yaz, "W" pour Yaw, etc.).
[^] # Re: Utilisation dans Latex/DocBook.
Posté par med . Évalué à 2.
Est-ce que ce sont des variantes suivant la locale, par exemple une lettre arabe dessinée différemment en farsi (dans ce cas cela pourra se résoudre avec les fonctions OpenType), ou bien ce sont vraiment deux alphabets incompatibles, chacun ayant son école ?
[^] # Re: Utilisation dans Latex/DocBook.
Posté par Anonyme . Évalué à 2.
L'erreur serait d'opter pour un type d'alphabet, comme celui qui a été figé par l'IRCAM par exemple, et se mettre à dos les Touaregs ou les Kabyles :-D
Histoire d'élargir, il existe un clavier pour le tifinagh (dans un paquet Mandriva, hop rpm2tgz au besoin), mais il est taillé pour l'alphabet IRCAM. J'avais envisagéé de le dupliquer, mais pour le moment je ne puis m'y mettre.
[^] # Re: Utilisation dans Latex/DocBook.
Posté par ookaze . Évalué à 4.
"Disponible" étant ce que tu as demandé. Une police peut être présente sur ton système, mais non pris en compte (bon, peut-être pas dans une distro).
En ce qui concerne Gnome, Gucharmap te permet de voir les fontes par défaut (ou configurées) utilisées, et un clic droit (de mémoire) sur un caractère te permet de voir de quelle fonte il est tiré (très utile pour tester sa config fontconfig).
# Merci
Posté par Mark Havel . Évalué à 6.
Grâce à cet ensemble de fontes, une fois le Firefox réglé correctement, tout fonctionne bien, j'ai de belles polices affichées dans des tailles raisonnables et tout est bel et bon. Vous avez donc fait au moins un utilisateur heureux.
# Metafont
Posté par salvaire . Évalué à 8.
[^] # Re: Metafont
Posté par med . Évalué à 6.
Pour le kerning, les ligatures et tout le reste, c'est typiquement un travail qui doit se faire largement à la main. Ce n'est pas un hasard si les fonderies vendent leurs fontes à un tarif élevé, elles nécessitent beaucoup de travail.
Pour le reste, n'étant pas l'initiateur des moteurs de rendu sous linux et ayant une connaissance relativement limitée de ceux-ci, il faudrait demander aux spécialistes pourquoi on s'oriente de plus en plus vers des polices vectorielles de type OpenType. Pour le reste, OpenType ce n'est pas seulement Microsoft, c'est aussi Apple (qui détient malheureusement des brevets utiles dessus) et dont la qualité typographique est très bonne. Je présume que ça doit avoir un certain nombre d'avantages déterminant par rapport à metafont. Mais en quoi les polices OpenType sont-elles grasses ? Personnellement je ne trouve pas. Ne ferais-tu pas à tout hasard référence à des fontes n'utilisant pas d'algorithmes d'optimisation (qui existent précisément pour avoir des contours très tranchés) ?
[^] # Re: Metafont
Posté par moyogo . Évalué à 4.
Les polices DejaVu utilisent le format OpenType avec des contours TTF, ce qui veut dire qu'elles peuvent pleinement profiter des qualités d'OpenType et être utilisées sur toutes applications supportant ce format devenu le standard incontesté.
[^] # Re: Metafont
Posté par salvaire . Évalué à 2.
D'après le pdf de démo de DejaVu. J'ai l'impression que cette police est grasse par rapport à "crm", ce style est typique des ".doc" illisible. C'est mon goût.
[^] # Re: Metafont
Posté par med . Évalué à 2.
[^] # Re: Metafont
Posté par moyogo . Évalué à 1.
Il est évident que la police DejaVu n'est pas une police légère.
La majorité de police Sans sont d'habitute de gras "Book" ou "Medium".
Il y a dans les polices DejaVu une police Sans ExtraLight qui vise à être très, très légère. D'autres police intermédiaire pourraient être interpolées pour avoir plusieurs gras disponibles.
# Et l'occupation mémoire dans tout ça ?
Posté par ldng . Évalué à 4.
Parce une fonte UTF-16, j'imagine, occupe plus de mémoire qu'une simple latin 1. Ne serait-il pas plus judicieux de la split en fonction de sous-ensemble couverts ?
[^] # Re: Et l'occupation mémoire dans tout ça ?
Posté par med . Évalué à 4.
Sinon, il me semble qu'avoir une fonte complète qui couvre le plus de caractères possibles est plus efficace que d'avoir plein de fontes qui chacune n'ont qu'une couverture beaucoup plus partielle.
Pour le moment la taille de DejaVu reste faible en comparaison de polices beaucoup plus complètes comme Code2000 ou Arial Unicode. L'évolution des machines est telle, que lorsque DejaVu atteindra ces tailles, cela ne posera pas vraiment de problème au regard de la RAM. Cependant pour des machines assez limitées on réfléchit à une manière automatisée de construire des version allégées (par exemple pour un ordi à 100$), ce cette façon tout le monde sera content.
[^] # Re: Et l'occupation mémoire dans tout ça ?
Posté par Aldoo . Évalué à 5.
UTF-16 (ou UTF-8) est un codage (une représentation) de caractères, alors qu'unicode est une norme définissant une liste de glyphes, et associant un numéro unique à chacun. Ce numéro peut ensuite être codé en UTF-xx (remplacer xx par 8,16,32,42... ).
Dire que la fonte vise à couvrir (telle ou telle partie d')Unicode, veut dire que, dans la fonte, il y a un dessin pour chaque glyphe d'Unicode (ou de la partie concernée). Après, on peut s'en servir pour afficher un texte en UTF-8, UTF16, iso8859-xx (vu que tous les caractères des iso8859-xx sont dans Unicode) ou autre.
[^] # Re: Et l'occupation mémoire dans tout ça ?
Posté par moyogo . Évalué à 4.
Unicode code les caractères et non les glyphes.
Un même caractère peut donc couvrir plusieurs glyphes (ex : б U+0431 qui a un glyphe différent selon la locale russe ou serbe) et un même glyphe peut se trouver dans plusieurs caractères.
Ludovic: C'est vrai que tout le monde n'a pas besoin de la couverture complète d'Unicode. Les développeurs en sont conscients et une solution devrait être disponibles à un moment ou l'autre.
[^] # Re: Et l'occupation mémoire dans tout ça ?
Posté par Aldoo . Évalué à 2.
Je pensais plutôt au fait qu'Unicode distinguait deux caractères (à deux usages différents), mais avec deux dessins (glyphes !) quasi-identiques. Le truc qui avait créé une faille de sécurité il y a quelque temps avec les URL unicode.
Mais bon, le point essentiel de mon commentaire était qu'Unicode ne dit pas comment chaque caractère doit être codé en pratique dans un fichier informatique ou dans la représentation mémoire d'une chaîne de caractères.
[^] # Re: Et l'occupation mémoire dans tout ça ?
Posté par Pierre Jarillon (site web personnel) . Évalué à 5.
C'est le pishing. C'est ainsi que pour un a remplacé par un caractère quasi-identique, certains se sont fait arnaquer par des escrocs, croyant être sur ebay...
[^] # Re: Et l'occupation mémoire dans tout ça ?
Posté par Anonyme . Évalué à 1.
Ce cas-là ne se présente qu'en cas de différenciation par la locale, non ?
[^] # Re: Et l'occupation mémoire dans tout ça ?
Posté par herodiade . Évalué à 3.
http://bugzilla.gnome.org/show_bug.cgi?id=334758
Notez que les participants au débat (Behdad Esfahbod, Owen Taylor etc.) sont vraiment des core-hackers de gnome ou x.org, et savent de quoi ils parlent.
En bref: ils pense que c'est pas un choix pertinent, qu'il faudrait plutôt spliter DejaVu et la question de poid en mémoire n'est pas le seul problème (cf. l'exemple dans le commentaire #27).
Un exemple de problème intéréssant soulevé par Behdad, c'est que cette approche l'empêche d'utiliser DejaVu pour les scripts latins et choisir simultanément une police rendant correctement les caractères Arabes à la façon Perse (puisque le tout en un DejaVu contraint l'utilisation d'un seul type de glyphe pour un caractère donné).
Une conséquence dommage, c'est que DejaVu était bien présentie pour être la font par defaut de plusieurs distributions, et celles-ci (à ma connaissance, Ubuntu et Fedora) sont en train de revenir d'urgence sur Bitstream, à cause des problèmes induits par l'approche "all in one" (et de certains bugs non corrigés dans DejaVu).
cf. par ex. https://launchpad.net/distros/ubuntu/+source/fontconfig/+bug(...)
Quelle est la position des developpeurs de DejaVu concernant cette question ? envisagent-ils de splitter DejaVu pour les scripts non latins ?
[^] # Re: Et l'occupation mémoire dans tout ça ?
Posté par moyogo . Évalué à 3.
La position des developpeurs a été de proposer une version limitée aux écritures latine, grecque et cyrillique : DejaVu LGC. Celle-ci est sortie en même temps que la première version de DejaVu Sans avec les additions arabes.
Pour le style farsi, le problème est vraiment dans les librairies comme Pango. Donnez nous un support pour la fonction OpenType 'locl' et nous aurons des polices qui s'adaptent à votre style favori selon la langue indiquée. Et oui, pas besoin de changer de police pour avoir des styles différents. Simplement besoin de librairies et de programme plus intelligent. Si Pango ou Qt nous permettaient cela, DejaVu aurait déjà des caractères pour le style farsi.
De plus les problèmes liés à l'incompatibilité de métrie entre les différents système d'écriture est encore une fois la faute des librairies (ou logiciels de conceptions de police). Celles-ci ne permettent pas d'avoir un table BASE qui définit différentes lignes de bases de caractères pour différentes écritures.
[^] # Re: Et l'occupation mémoire dans tout ça ?
Posté par herodiade . Évalué à 2.
En lisant ta réponse j'ai quand même gardé cette question en tête, en pensant (à tord ou à raison ?) que ce genre de « split » (comme LG, mais aussi pour les autres familles) serai une réponse pragmatique :
- Un contournement des bugs et limitations des logiciels dont tu parle (Pango, Qt, et peut-être d'autres ? - si on veut utiliser DejaVu sur d'autres OS, eg. en l'incluant dans un fichier ps, odf ou pdf ? et lorsque les bugs seront corrigés: la rétro-compatibilité avec les vieilles versions bugguées ?). Si j'ai compris ce que tu expliquais, le parti pris actuel semble être assez exigeant, et aurai tendance à butter sur les bugs des libs sous-jacentes (est-ce souhaitable ?)
- Une certaine souplesse pour l'utilisateur dans le choix de ses polices (même sans parler des « styles » comme ci-dessus). Comme DejaVu LG lui permet déjà de choisir la meilleure pour les scripts latins (et une autre pour des scripts différents où DV n'est pas la meilleure), on pourrai imaginer qu'un autre utilisateur souhaiterai utiliser DV pour afficher l'arabe et autre chose pour l'ASCII/latin, et encore autre chose pour ses formules mathématiques. De plus, lorsque la couverture d'une écriture par DV est légèrement incomplète, ce serait peut-être une solution temporaire pour qu'un utilisateur de cette écriture puisse basculer facilement vers un support complet mais moins beau, si cette incomplétude le gène trop ?
- La question du poid et de l'utilisation des ressources (à tout niveaux: poid en mémoire, sur le disque, téléchargements/updates, ...) qui reste effective, surtout si DejaVu est susceptible de progresser très vite et de couvrir de très nombreuses écritures, ou lorsqu'on veut l'utiliser pour de l'embarqué (PDA en Arabe, téléphone en Coréen, OLPC en Afrique ...), ou incluse dans des documents qu'on redistribue.
Par exemple: le jour ou DejaVu couvrira la totalité des 10000+ Kanjis (Japonais), un utilisateur arabophone aura le dilemne entre choisir DV LG + une autre police pour l'Arabe, ou DejaVu normal et une grosse utilisation de ressources ; réciproquement pour un utilisateur Japonophone. Une famille de polices façon "DejaVU LG", "DejaVu Arabic", "DejaVu Kanjis", "DejaVu Kanas", ... leur permetrai de choisir les composants qui les intéressse, non ? D'autre part, le calcul du rendu des chaines ne risque-t-il pas d'être ralenti si Pango & co ont besoin de parcourir, à chaque caractère, un grand nombre de glyphes pour trouver celui qu'il doit afficher ?
Est-ce que je me gourre / suis tout à fait à coté de la plaque ?
Et aussi, du coup, si la position des développeurs de DejaVu a été de proposer une version LG réduite aux caractères latins, est-ce que leur position sera aussi de proposer des versions réduites de ce type pour les caractères Arabes etc. ? Quels sont les avantages de distribuer, comme aujoud'hui, tout en un (avec seulement une possibilité de choix pour les caractères de DejaVu LG) ?
[^] # Re: Et l'occupation mémoire dans tout ça ?
Posté par med . Évalué à 2.
J'espère que pas mal des problèmes des bibliothèques sous-jacentes seront résolus à ce moment là. :)
Ça peut être intéressant mais pénalisant niveau temps (voir ci-dessous). Ça pose aussi un problème au niveau des références (des caractères visuellement identiques ne sont pas dessinés plusieurs fois). C'est bien évidemment soluble, mais il faut que quelqu'un écrive un Makefile assez rusé pour ça.
On m'a dit (c'est à vérifier donc), que le plus pénalisant est de procéder à des substitutions. Donc a priori il est plus rapide d'avoir une fonte contenant beaucoup de caractères que beaucoup de fontes qui contiennent peu de caractères. Il serait intéressant de voir comment évolue le temps d'accès à un caractère suivant la taille de la fonte. J'ose espérer que c'est plutôt constant en temps. :)
J'y pense, j'ai cru entendre dire que fontconfig est (sera ?) capable de gérer les priorités des différentes fontes suivant la langue. Dans ce cas ce serait vraiment idéal. Plus besoin de s'arracher les cheveux à faire différentes version de DejaVu. L'utilisateur n'a qu'à choisir sa fonte préférée suivant la langue.
# Italique
Posté par tzeentch00 . Évalué à 3.
[^] # Re: Italique
Posté par moyogo . Évalué à 2.
[^] # Re: Italique
Posté par reno . Évalué à 3.
[^] # Re: Italique
Posté par moyogo . Évalué à 3.
En fait par italique, r¹° a voulu dire italique cursive par opposition à italique oblique ou italique penchée.
Les italiques dites penchées ou obliques sont simplement les même caractères que dans la forme normale, mais penchées à un certain angle.
Les italiques dites cursives, en somme les «vrais italiques», ne sont pas des copies penchées mais ont des tracés cursifs (comme si fait à la main d'un trait avec des angles arrondis) et généralement plus étroits. Ceci leurs permet d'être plus agréable à l'oeil.
Pour plus d'infos : http://fr.wikipedia.org/wiki/Italique
# En savoir plus sur les polices de caractère libres
Posté par yosch . Évalué à 6.
http://unifont.org/fontguide/ : le "Unicode Font Guide For Free/Libre Open Source Operating Systems" d'Ed Trager
http://scripts.sil.org/OFL_fonts : le catalogue de polices de caractères sous Open Font License (http://scripts.sil.org/OFL) de la SIL.
L'OFL est une license libre reconnue par la FSF pour les polices de caractères (http://www.fsf.org/licensing/licenses/index_html#Fonts) qui respecte les 4 libertés fondamentales du Logiciel Libre et qui satisfait aux exigences des typographes et des créateurs de fontes en matière d'intégrité artistique.
La typographie libre est un très bon moyen pour qu'il existe un jour une mise en oeuvre esthétique et fonctionnelle de toutes les langues du monde peu importe la complexité de leur système d'écriture ou le nombre éventuellement trop réduit de locuteurs.
[^] # Re: En savoir plus sur les polices de caractère libres
Posté par yosch . Évalué à 1.
# HarfBuzz
Posté par Thomas Linard (site web personnel) . É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: HarfBuzz
Posté par med . Évalué à 3.
La prise en charge est déficiente pour pango aussi (par exemple pas de choix pour les variantes stylistiques, etc.), on a régulièrement des problèmes. Il ne faut malheureusement pas se faire d'illusion là-dessus.
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).
[^] # Re: HarfBuzz
Posté par Thomas Linard (site web personnel) . É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.
[^] # Re: HarfBuzz
Posté par med . Évalué à 2.
[^] # Re: HarfBuzz
Posté par moyogo . Évalué à 2.
Pango gèrent les fonctions OpenType de base nécessaires à écriture dites «simples», et ce depuis la version 1.11. 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'). Comme susmentionné, les variantes selon la locale ('locl') ne sont pas encore supportées.
Pour les petites capitales, variante stylistique de chiffres, et autre type de notations, il faudra être patient. Il faudrait que Pango/Qt4/Harfbuzz permettent d'appliquer les fonctions OpenType d'une manière plus souple et modulaire que le système actuel, limité par écriture. De plus il faudrait une interface commune pour y accéder dans les dialogues de sélection de police de caractère.
[^] # Re: HarfBuzz
Posté par Thomas Linard (site web personnel) . É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 yosch . Évalué à 2.
Il est en cours d'intégration dans GTK+/GNOME, OpenOffice.org et Mozilla.
Tous les détails sur http://graphite.sil.org
La librairie est déjà dispo dans Debian (et aussi Ubuntu):
http://packages.debian.org/unstable/libs/libgraphite2
Et les développeurs de Scribus et d'Inkscape - entres autres - sont au courant et plutôt intéressés.
[^] # Re: HarfBuzz
Posté par Thomas Linard (site web personnel) . É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 moyogo . Évalué à 2.
Un des problèmes majeurs de toutes ces belles fonctions est qu'il est impossible de les échanger entre applications. À moins que celles-ci ne sorten de la même boite ou lisent/écrivent parfaitement un même format. Ces biens dommage qu'il n'y ai pas moyen de simplement copier-coller en application en gardant les attributs stylistique ou encore de les utiliser avec CSS sur le web ou autre plateforme utilisant le *ML.
[^] # Re: HarfBuzz
Posté par Thomas Linard (site web personnel) . É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.»
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.