Journal Le saviez-vous?

Posté par  . Licence CC By‑SA.
Étiquettes :
39
16
sept.
2020

Désolé, je m'ennuies un peu (ce qui explique le titre fainéant), j'ai donc décidé de vous partager ce point de savoir inutile:

Le standard X11 actuel, que l'on pourrais donc dire «moderne» supporte un certain nombre de formats de fichiers pour décrire une fonte.
Parmi ces formats, l'on peut noter le format bdf.

Parmi les choses "à savoir", il semble que:

1) X11 se base sur la version 2.1 du format, alors que la version 2.2 du format, parue en 1993, permets une réduction non-négligeable de la taille du fichier décompressé (~10% sur le fichier qui m'a servi d'exemple) ainsi que du temps de parsing (de 0.25s à 0.20s). J'ai utilisé le fichier de fontes japonaises issu de ce site que j'ai migré vers la 2.2 pour le fun (un coup de sed, et c'est réglé, vraiment). La raison? Cette mise à jour permets, notamment, de spécifier des paramètres par défaut qui s'appliquerons à chaque glyphe!

2) X11 semble ne pas avoir été heureux des fins de lignes, et a décidé qu'il était pertinent d'introduire une nuance dans le format de fichier pour un sujet aussi important.

3) La version 2.2 (de 1993 toujours) introduit le support des scripts qui ne se suivent pas en ligne! Mais en lisant la spec de la version 2.1, on échoue a comprendre ce qu'il y a en plus: DWIDTH est complété par DWIDHT1 et VVECTOR, mais l'intérêt est difficile à comprendre… vu que les offset pour calculer le prochain origin ont des valeurs X et Y!

4) la version 2.2 donne un example de la version… 2.1!

5) X11 utilisais soit un encodage perso en 1er champ, soit l'encodage d'adobe, aka postscript, lequel ne semble plus trop documenté. En pratique, je suis persuadé qu'il s'agit d'un encodage perso, donc, le X11BDF en plus d'être inutilement lent et peu performant, en plus ne respecte pas les formats!

Et pour ceux qui se demandent, oui, je m'amuse coder un parseur bdf. Ce format est raisonnablement simple à implémenter, et plus esthétique que le monospace PSF.
Vu qu'il est implémenté en texte, j'ai même pu écrire une syntaxe bdf, que je partagerais peut-être, si vous êtes sages (même si tout le monde s'en fout en vrai) quand je l'aurais finit (en vrai ça complèterais pas mal mon quick-start, avec un cas d'usage réel)

Bonne nuit a ceux qui dorment pas encore :)

  • # Explications ?

    Posté par  . Évalué à 8 (+5/-0).

    Il y a une raison/justification pour ne pas prendre en charge la version 2.2 par X11 ?

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Explications ?

      Posté par  . Évalué à 4 (+2/-0).

      Personne n'a jugé utile/nécessaire de s'y coller ?
      (supposition de ma part)

    • [^] # Re: Explications ?

      Posté par  . Évalué à 4 (+3/-1).

      Il y a une raison/justification pour ne pas prendre en charge la version 2.2 par X11 ?

      Qui utilise la gestion des polices de caractères de X11 en 2020 ? Je suppose que la gestion des polices de caractères se fait essentiellement dans GTK ou Qt.

      Il y a un an Christian Schaller de Red Hat écrivait sur son blog qu'une fois les améliorations Wayland terminées, X.org passera assez rapidement en mode de maintenance intensive. X11 sera supporté jusqu'au 31 mai 2029 date de la fin de vie de RHEL8. X.org étant principalement supporté par Red Hat, l'avenir de la pile graphique est Wayland.

      • [^] # Re: Explications ?

        Posté par  . Évalué à 10 (+9/-0).

        une fois les améliorations Wayland terminées

        Ça va alors, on a encore le temps. Oups, ce n'est pas encore troldi?

      • [^] # Re: Explications ?

        Posté par  . Évalué à 3 (+1/-0).

        D'un autre côté, de que je comprend de wayland, justement, chaque application, ou plutôt chaque toolkit, devra gérer son texte sois-même, wayland offrant, en gros, un framebuffer à l'application qui… en fait ce qu'elle veut.
        Je pense sincèrement que ça fait sens, compte tenu du fait que l'informatique n'est plus distribuée de la même façon que dans les années 70 (mainframes).

        Mes errances n'ont pas pour but de taper sur Xorg, juste d'essayer un peu de comprendre le boxon qu'est la stack graphique, et essayer de m'en servir en tant que dev qui aime comprendre ce qu'il fait. Ce qui implique parfois de réinventer les roues en moins rondes, mais je l'assume :)

  • # Le B.A. BA du béotien

    Posté par  . Évalué à 5 (+4/-0).

    Hello,

    Et pour le béotien que je suis, au final quel serait l'apport de l'intégration du format .bdf 2.2, de 1993 ;-) dans X11

    Un parallèle avec Wayland ? (pour rappel je suis béotien complet, j'ai relu tes écris plusieurs fois avant de ne pas comprendre)

    Julien_c'est_bien (y'a pas que Seb)

    • [^] # Re: Le B.A. BA du béotien

      Posté par  (site Web personnel) . Évalué à 9 (+7/-0).

      La plupart du temps les polices utilisées sont au format ttf (via l'extension Xft) et de toutes façons, même ça, c'est pas super utilisé par GTK ou Qt qui se débrouillent de leur côté pour faire le rendu du texte, et demande juste à X d'afficher l'image résultante.

      Donc une nouvelle version sortie il y a 28 ans d'un format obsolète que personne n'utilise pour 2 raisons, ça va pas apporter grand chose.

      • [^] # Re: Le B.A. BA du béotien

        Posté par  . Évalué à 2 (+1/-0).

        Hello,

        Je comprends mieux les problèmes que j'ai pu avoir à faire manger du .ttf à ma Ubuntu alors, elle l'a pas assimilé du tout la fois ou j'ai essayé :-)

        Julien_c'est_bien (y'a pas que Seb)

      • [^] # Re: Le B.A. BA du béotien

        Posté par  . Évalué à 4 (+2/-0).

        c'est pas super utilisé par GTK ou Qt qui se débrouillent de leur côté

        De ce que je sais (pas grand chose, mais regarder les résultats de ldd $(which foobar) aide à apprendre, ou au moins a se poser des questions) gtk comme qt se basent sur freetype pour charger les fontes à partir des fichiers, pour gérer le format, donc, et un peu le rendu.
        Ensuite, il y a au moins harfbuzz qui entre en jeu, peut-être pour gérer les offsets des glyphes (oui, je dis bien glyphes, et pas caractères) qui déterminent la position du suivant.

        Après, la raison pour laquelle je joue avec, c'est tout simplement pour pouvoir revenir à un peu moins de complexité dans le code, tout en n'ayant pas un truc aussi moche que du monospace permanent (c'est bien dans certains cas, le monospace, mais ça s'arrête aux écrits techniques comme du code source par exemple).
        Pour un de mes projets perso, je souhaite en fait pouvoir simplement tourner dans du framebuffer, et honnêtement, freetype, c'est super, mais aussi super compliqué. Ajouter le reste des libs en séries pour espérer avoir un code qu'on ne comprend pas et qui marche peut-être… J'ai donc voulu me pencher un peu sur ces formats obsolètes, et ai livré quelques infos ici même.

        Ce n'est bien sûr pas d'un grand intérêt, sauf pour ceux qui parfois veulent juste bricoler un truc à la va-vite.
        Enfin, pour ça, une lib serait plus utile qu'une spec à la qualité un peu hasardeuse, forcément.

Envoyer un commentaire

Suivre le flux des commentaires

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