DejaVu, la famille de fontes libres de référence

Posté par . Modéré par Pascal Terjan.
Tags : aucun
0
15
mai
2006
Serveurs d'affichage
DejaVu est une famille de fontes sous licence libre dérivée de Bitstream Vera. Son objectif est de fournir une plus grande couverture d'unicode tout en maintenant l'aspect original en utilisant un mode de développement collaboratif. La famille est disponible en tant que fontes OpenType TTF.

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

  • # Merci pour cette dépèche

    Posté par (page perso) . Évalué à 6.

    Grâce a toi j'ai enfin compris ce qu'étais ces Sans et Sherif...

    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 . Évalué à 6.

      Malheureusement j'ai peur que ce ne soit pas grâce à DejaVu que tu vois le japonais correctement. Il n'est pas inclus dedans : http://svn.sourceforge.net/viewcvs.cgi/dejavu/trunk/dejavu-f(...) . Dans ces cas là c'est fontconfig qui se charge de trouver une autre fonte pour faire la substitution. Cependant si un jour quelqu'un arrive à produire des caractères japonais de bonne qualité, dans le style et la métrique de DejaVu, il y a de bonnes chances que ce soit intégré. Pour l'instant c'est pas prioritaire cependant. Pour le travail en cours ou les caractères demandés : http://dejavu.sourceforge.net/wiki/index.php/Plans .
    • [^] # Re: Merci pour cette dépèche

      Posté par (page perso) . Évalué à 9.

      A mon tour de remercier l'auteur qui m'a fait découvrir qu'il y avait des algos d'optimisation derrière chaque caractère !

      J'étais loin d'imaginer le travail que cela représente.
    • [^] # Re: Merci pour cette dépèche

      Posté par . Évalué à 6.

      Grâce a toi j'ai enfin compris ce qu'étais ces Sans et Sherif...
      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 . Évalué à -2.

    Hum. Y'a pas, dans un vrai format, genre Type 1 ou Type 3 ?

    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 . Évalué à 10.

      Les fontes ne sont pas au format TTF pur, elles sont au format OpenType : http://en.wikipedia.org/wiki/OpenType qui gère les ligatures et tout un tas d'autres choses. Pour l'instant le facteur limitant n'est pas OpenType mais la gestion d'OpenType dans pango et Qt qui est très limitée et relativement buguée. Comme je l'ai indiqué, la situation devrait fortement s'améliorer grâce au projet harfbuzz qui fédère les efforts de pango et Qt.
      • [^] # Re: TTF ?

        Posté par . Évalué à 1.

        Merci de la précision.
        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 (page perso) . Évalué à 3.

    Est-ce que je peux "facilement" utiliser cette font pour mes documents latex/docbook etc ?

    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 . Évalué à 2.

      Je n'ai pas encore essayé, mais on m'a communiqué le lien suivant : http://www.cs.put.poznan.pl/csobaniec/LaTeX/index.html qui explique (entre autres) comment utiliser une fonte TTF avec LaTeX.

      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 . Évalué à 1.

        Ou xlsfont, d'ailleurs. Sinon, ça fait une police de plus qui contient le tifinagh ! \o/
        • [^] # Re: Utilisation dans Latex/DocBook.

          Posté par (page perso) . Évalué à 7.

          Pour ceux qui se posent la question, le tifinagh est un alphabet utilisé par les Berbères, et plus particulièrement par les Touaregs.
        • [^] # Re: Utilisation dans Latex/DocBook.

          Posté par . Évalué à 6.

          Je suis désolé de tempérer ton enthousiasme, mais les caractères nécessaires au tifinagh ne sont malheureusement pas encore dans DejaVu. Tu as dû te faire tromper par fontconfig je pense. Cependant à les voir ils ne m'ont pas l'air très difficiles à dessiner. Si tu les demandes sur la liste de diffusion, peut-être que ça intéressera quelqu'un de les faire. Ou bien les faire toi-même si ça t'intéresse et que tu as un peu de temps devant toi.

          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 . Évalué à 2.

            En lisant la couverture unicode de DejaVu (http://linuxfr.org/redirect/46903.html), j'était parvenu à la conclusion que l'alphabet tifinagh était couvert.

            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 . Évalué à 2.

              La difficulté principale est qu'il existe plusieurs versions de cet alphabet.


              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 . Évalué à 2.

                Ce sont des variantes suivant la locale. Je pense qu'il suffit donc de répertorier toutes les lettres. Donc comme tu l'entends, ce n'est pas une grande difficulté en soi.

                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 . Évalué à 4.

      Pour les polices dispo, les environnements KDE et Gnome ont chacun une appli permettant d'afficher toutes les polices disponibles.
      "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 . Évalué à 6.

    Je viens d'installer ces nouvelles polices et c'est le bonheur complet pour mon Linux : enfin un rendu des fontes correct pour mon Mozilla Firefox. Avant, c'était l'enfer, soit je me résignais à régler la bestiole en fontes de tailles d'au moins 15 pour avoir un truc correct, soit je me tapais des fontes minuscules pour certains sites comme le New York Times. Sans compter les commentaires de LinuxFR où les lettres pouvaient varier de taille selon la lettre.

    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 . Évalué à 8.

    FontForge semble être entièrement basé sur un gui (pour ne pas dire un clickodrôme). Metafont conçu il y à 20 ans, est un langage de programmation spécialisé dans les polices. Cela permet de réutiliser des parties (e.g. patte des polices), de faire varier les polices ... Doit on tout cliquer à la souris dans FontForge? De même les problèmes de kerning, ligature, variante, et rendu professionnel sont en partie résolu depuis des lustres. Bien sûr le support des polices vectorielles est absent. Mais les polices vectorielles ne sont pas si lisible que ça. Voir le livre Français sur Metafont pour quelques exemples. Pourquoi ne pas avoir utilisé Metafont comme point de départ pour les polices sous Linux? Préfère on copier Microsoft, ses technologies et ses polices grasse, trop grasse!
    • [^] # Re: Metafont

      Posté par . Évalué à 6.

      Fontforge est un logiciel scriptable, donc non, on ne doit pas forcément tout faire à la souris. D'ailleurs le plan braille a été dessiné avec un petit script maison en python (qui génère des instructions lisibles par fontforge). Mais pour faire du dessin, une interface graphique est tout de même bien pratique je trouve. Enfin, chacun ses goûts. :)

      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 . Évalué à 4.

        Metafont n'a pas été choisi tout simplement parce que les polices de départ étaient Bitstream Vera en format TTF. Il y avait déjà des instructions d'optimisation de caractère, des ligatures et du crénage (kerning). De plus le format TTF est beaucoup plus multiplateforme. Peut-on utiliser une police Metafont sur Windows/Mac/Linux sans devoir absolument passer par TeX ?
        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 . Évalué à 2.

        pour faire du dessin, une interface graphique est tout de même bien pratique
        Certainement. Les deux sont nécessaires. Metafont nécessite une mise à jour. Mais le travail de D. Knuth est une base sûr!

        Mais en quoi les polices OpenType sont-elles grasses ?
        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 . Évalué à 2.

          Il faut voir que les PDF de démos sont construits avec un corps bien supérieur à celui d'une utilisation normale. De plus, il n'est pas dit que le hinting soit utilisé, en tout cas avec kpdf il semblerait qu'il ne l'est pas (c'est peut-être ma configuration locale qui veut ça), ce qui rend les caractères assez baveux pour tout dire. Après, comme tu dis, chacun ses goût. :)
          • [^] # Re: Metafont

            Posté par . Évalué à 1.

            À propos de graisse : Chaque police à une graisse différente.
            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 . Évalué à 4.

    C'est bien beau d'avoir une police qui couvre tout l'unicode (que je suppose être UTF-16), mais est-il possible de limiter son usage au latin 1 par exemple ?
    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 . Évalué à 4.

      Si tu veux te limiter au latin-1, tu peux utiliser Bitstream Vera, on se base là-dessus.

      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 . Évalué à 5.

      Une fonte peut couvrir Unicode... mais pas UTF-16 !

      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 . Évalué à 4.

        Unicode n'est pas une norme définissant une liste de glyphes, bien au contraire. C'est une norme définissant des caractères et celle-ci est code en différents formats (UTF-16, UTF-8, etc.).

        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 . Évalué à 2.

          Oups, petite confusion, désolé ;-)

          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 (page perso) . Évalué à 5.

            Le truc qui avait créé une faille de sécurité il y a quelque temps avec les URL unicode.


            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 . Évalué à 1.

          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.


          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 . Évalué à 3.

      Sur le sujet de la pertinence d'inclure tout (y compris les scripts non latins) dans la même version de DejaVu (plutôt que de faire, par exemple, une "DejaVu Arabic"), il y a un gros débat ici:

      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 . Évalué à 3.

        Quelle est la position des developpeurs de DejaVu concernant cette question ? envisagent-ils de splitter DejaVu pour les scripts non latins ?

        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 . Évalué à 2.

          Ah ok, merci beaucoup pour l'explication poitue, je comprend (un peu) mieux.
          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 . Évalué à 2.

            Par exemple: le jour ou DejaVu couvrira la totalité des 10000+ Kanjis (Japonais)


            J'espère que pas mal des problèmes des bibliothèques sous-jacentes seront résolus à ce moment là. :)

            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 ?


            Ç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.


            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 ?


            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 . Évalué à 3.

    Dans la dépêche il est mentionné une version italique de la police mais sur le wiki dejavu je ne voit qu'une version oblique. Ai-je loupé quelque chose et la version italique existe-t-elle vraiment ?
    • [^] # Re: Italique

      Posté par . Évalué à 2.

      Tu as raison r¹°. Il n'y a que des versions obliques. DejaVu Serif à un semblant d'italique.
      • [^] # Re: Italique

        Posté par . Évalué à 3.

        Bon je me lance: quelle est la différence entre les deux?
        • [^] # Re: Italique

          Posté par . Évalué à 3.

          Bon je me lance: quelle est la différence entre les deux?

          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 . Évalué à 6.

    Pour en savoir plus sur les divers projets de polices de caractères libres qui existent actuellement et peut-être même y contribuer, je vous recommande deux sites web bien fait et susceptibles de devenir de plus en plus actifs :

    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.
  • # HarfBuzz

    Posté par (page perso) . Évalué à 5.

    Bonjour,

    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.
    • [^] # Re: HarfBuzz

      Posté par . Évalué à 3.

      Bref, c'est bien pour Qt dont la prise en charge d'OpenType était réputée moins bonne


      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.

      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.


      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 (page perso) . Évalué à 2.

        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.
        • [^] # Re: HarfBuzz

          Posté par . Évalué à 2.

          Ah, je comprends mieux ce que tu veux dire maintenant. Mais ne serait-ce justement pas le travail d'harfbuzz d'implémenter tout ça ? En tout cas, au niveau de DejaVu, ça nous aiderait beaucoup. Y'a un certain nombre de choses assez frustrantes pour le moment.
        • [^] # Re: HarfBuzz

          Posté par . Évalué à 2.

          Pango, comme ICU (utilisé par OpenOffice), fourni une prise en charge d'OpenType pour les écritures dites complexes, pas les «simples» (latin, cyrillique, grec).

          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 (page perso) . Évalué à 1.

            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.


            Exactement.
        • [^] # Re: HarfBuzz

          Posté par . Évalué à 2.

          Il existe bel et bien un moteur de rendu des scripts complexes libre et multiplateforme : Graphite.

          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 (page perso) . Évalué à 3.

            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.
            • [^] # Re: HarfBuzz

              Posté par . Évalué à 2.

              Pour l'instant je n'ai pu testé que les fonctions Graphite qui s'occupaient des positionements et substitutions nécessaires aux différents systèmes d'écriture. Est-ce que Graphite gère les fonctions pour faire de la belle typographie comme vous dites, et avec quelle interface ?

              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 (page perso) . Évalué à 0.

                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.»

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.