Cairo 1.2 met le feu

Posté par  . Modéré par Jaimé Ragnagna.
Étiquettes :
0
1
juil.
2006
Technologie
Cairo est une bibliothèque graphique 2D qui permet de générer plusieurs types de sortie, soit en mode image, via les backends image, xlib et win32, soit en mode vectoriel, à l'aide des backends PDF, Postscript et SVG. Elle incorpore aussi en certain nombre de backends expérimentaux, dont OpenGL (glitz), Quartz et XCB.

Elle est ou sera utilisée par un nombre croissant d'applications, comme par exemple librsvg, Mono ou les prochaines versions stables de Firefox et de Gnumeric. La suite du développement de Cairo sera principalement consacrée à l'optimisation et à l'amélioration des performances de Cairo.

La nouvelle version stable de la bibliothèque graphique Cairo vient de voir le jour. Les principales nouveautés sont l'officialisation des backends PDF et Postscript, ainsi que l'apparition du backend SVG. À la différence des versions expérimentales des backends PDF et Postscript présentes dans Cairo 1.0, les fichiers générés sont maintenant principalement vectoriels, et le recours à des images de substitution n'a lieu qu'en dernier ressort. C'est sur cette version que s'appuiera la très prochaine bibliothèque GTK+ 2.10 pour le support de l'impression.

Aller plus loin

  • # PDF généré : gestion du texte...

    Posté par  . Évalué à 5.

    C'est un PDF vraiment généré avec Cairo 1.2 ? Parce que justement là ils abusent des images : même le texte est mis sous forme d'image, non sélectionnable donc...

    • [^] # Re: PDF généré : gestion du texte...

      Posté par  (site web personnel) . Évalué à 3.

      Peut-être que dans cet exemple de PDF c'est fait exprès:
      minefield-working-bitmap-glyphs.pdf

      Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141

    • [^] # Re: PDF généré : gestion du texte...

      Posté par  (site web personnel) . Évalué à 5.

      C'est peut être du à un bug (?)

      Sur la page de cairo:


      Note however, that due to a known bug
      in the PDF backend, it is not currently possible to use a PDF viewer
      to select text in a PDF file generated by cairo. It is anticipated
      that this shortcoming will be addressed shortly in a subsequent
      release.

    • [^] # Re: PDF généré : gestion du texte...

      Posté par  . Évalué à 2.

      C'est un PDF vraiment généré avec Cairo 1.2 ?

      Oui.

      Parce que justement là ils abusent des images : même le texte est mis sous forme d'image, non sélectionnable donc...

      Le texte n'est pas sous forme d'image, se sont des bouts de polices embarquées.

      Mis à part le texte d'entête et de bas de page, qui sont des effectivement des images, mais seulement parce que la police est de type bitmap.

      Concernant le problème de sélection, c'est effectivement un bug, qui sera peut-être corrigé dans une prochaine version de la série 1.2, si ça n'implique pas de trop gros changement.

      L'objectif de cette série stable étant une bonne qualité de rendu, notamment en vue de l'utilisation par le module d'impression de gtk 2.10. Ce problème n'a donc pas été considéré comme bloquant.

    • [^] # Re: PDF généré : gestion du texte...

      Posté par  (Mastodon) . Évalué à 3.

      Cairo contient assez peu de primitives pour tracer du texte facilement, seulement quelques trucs très bas niveau... Le plus simple est d'utiliser Pango qui peut rendre directement sur une surface cairo. Pour l'avoir déjà fait, le couple Cairo+Pango, c'est vraiment surpuissant, je le recommande quand on ne veut pas utiliser Gtk par exemple.

    • [^] # Re: PDF généré : gestion du texte...

      Posté par  . Évalué à 1.

      De plus le rendu est crade (sous Acroread).

  • # question de vocabulaire

    Posté par  (site web personnel) . Évalué à 5.

    Une question d'informaticien amateur: qu'est ce qu'un "backends"?

    • [^] # Re: question de vocabulaire

      Posté par  (site web personnel) . Évalué à 3.

      C'est en quelque sort l' "endroit" ou le programme enverra les résultats.
      Backend xlib : xlib est la bibliothèque du serveur X -> écran
      Backend PDF : tu obtiens un PDF
      etc.

      • [^] # Re: question de vocabulaire

        Posté par  (site web personnel) . Évalué à 1.

        Il y a aussi

        xlib -> serveur Xprint -> imprimante !

        Bon ok, c'est peu utilisé, mais Firefox marche comme ca. C'est un peu dommage que cela ne se généralise pas, car le fait de passer par la couche X devrait assurer l'impression de quasiment toutes les applications.

        • [^] # Re: question de vocabulaire

          Posté par  . Évalué à -3.

          Tu surf avec ton imprimante ? :D

          "Firefox - Rediscover the Web"

        • [^] # Re: question de vocabulaire

          Posté par  (site web personnel) . Évalué à 2.

          L'architecture du libre dans toute sa gloire: comme les projets naissent et meurent sans arrêt, chacun redéveloppe sa propre couche pour ne pas trop dépendre des autres. Résultat: un empilement dément de technologies hétéroclites :) On a la même chose pour l'audio par exemple: A quand un player -> gstreamer -> esd -> jack -> alsa -> oss ? ;)

          bref j'ai plutôt l'impression que ça se calme en ce moment, les développeurs essaient d'utiliser des librairies bien établies comme gtk, et c'est une très bonne chose.

          • [^] # Re: question de vocabulaire

            Posté par  (site web personnel) . Évalué à 2.

            Je suis d'accord. Cependant, je trouve cela aussi très esthétique de lier l'impression d'une application graphique à un serveur X d'impression (Xprint). Il fallait y penser. Du coup, pas de bataille gnome/kde/gnustep, la solution est commune et marche partout, même pour les applications motif !

            Idem pour le son. Il y avait une solution basé sur une extension du protocole X (MAS si mes souvenirs sont bons). Son gros avantage, c'est qu'un ssh -X aurait pu rediriger le son comme le flux vidéo. Je ne trouve pas idiot que par défaut, le son suive l'image. A défaut, on doit avoir 5 serveurs de sons dont le pingoin moyen (moi) ne sais que faire...

    • [^] # Re: question de vocabulaire

      Posté par  . Évalué à 2.

      Ça m'a un peu embêté d'utiliser ce terme, mais je ne connais pas l'équivalent en français.

      Le backend est la partie de cairo qui va effectivement traduire les appels à cairo en une action dépendant du type de sortie désiré.

      Par exemple, pour les appels suivant:

      cairo_move_to (cairo, x0, y0);
      cairo_line_to (cairo, x1, y1);
      cairo_stroke (cairo);

      Le backend image va tracer une ligne en modifiant les octets d'un espace mémoire correspondant à une image.

      Le backend SVG lui, va stocker dans un fichier le code SVG qui décrit cette ligne, quelque chose du genre:



      L'intérêt d'une biliothèque graphique avec backend, c'est qu'en gros, le code pour tracer ne change pas, il suffit simplement de créer la surface correspondant au type sortie souhaité (cairo_image_surface_create ou cairo_svg_surface_create dans ce cas).

    • [^] # Re: question de vocabulaire

      Posté par  . Évalué à 9.

      Dans "backend" il y a plutôt l'idée d'arrière boutique.
      - dans cette arrière boutique le travail est effectué avant d'être mis a disposition.
      - l'arrière boutique est "cachée" pas besoin de voir comment cela se passe, le travail est fait c'est tout.

      Afin de pouvoir faire évoluer les 2 a des rythmes différents, il est courant de séparer les logiciel en une architecture frontend/backend. Le "frontend" est ce qui se voit (gui pour un logiciel, api pour une librairie), le backend est ce qui effectue le boulot (fonctions metier, base de donnée, code spécialisé ...).

      Apparement dans le cas de cairo on peut choisir des backend spécialisés dans le pdf, le svg, ... en fonction du besoin.

      ça vous plait comme explication ? :-)

      • [^] # Re: question de vocabulaire

        Posté par  . Évalué à 4.

        Dans "backend" il y a plutôt l'idée d'arrière boutique.

        Non, ça c'est "backoffice". "backend" et "frontend", ce sont simplement les "bouts" avant et arrière (d'un tuyau, par exemple).

        • [^] # Re: question de vocabulaire

          Posté par  . Évalué à 1.

          c'est la traduction litterale ça, or je n'essayais même pas de traduire mais plutôt d'expliquer avec des idée compréhensibles en français.
          va faire une explication imagée avec le bout arrière de tuyau :-)

          • [^] # Re: question de vocabulaire

            Posté par  . Évalué à 3.

            Moi j'en voit bien une, mais il faut savoir comment est faite la saucisse.

            Je m'y essaie quand meme, mais sans la saucisse ;) :
            Prenons GCC qui est lui même composé de front ends et de back ends:
            - en entrée, il accepte des programmes ecrits dans plusieurs langages de programmation (C, C++, Java, Ada, ...). Il va traduire la sémantique de ces programmes dans un format intermédiaire (commun a tous les langages). En fait, la partie centrale est commune (c'est le format intermediaire) mais la partie située en entrée (le front end) change selon le langage de programmation. Ici, le front end est est l'analyseur lexical et syntaxique.
            - en sortie, il permet de compiler dans plusieurs langages: A partir du format intermediaire (commun a tous les langages), il peut générer de l'assembleur pour processeur x86, UltraSparc, PowerPC, et même du bytecode Java. A partir de la partie centrale commune, la partie réalisant la sortie (le back end) change. Ici, le back end est le generateur de code.

            On voit donc bien que l'on a:
            - une partie en entrée qui peut changer (celle qui "accepte" un langage de programmation en entree),
            - une partie centrale toujours la meme (celle qui code la semantique d'un programme),
            - une partie en sortie qui peut changer (celle qui genere l'assembleur).

            J'espere que je n'ai pas embrouille les idees!

          • [^] # Re: question de vocabulaire

            Posté par  (site web personnel) . Évalué à 2.

            Une idée pour le tuyau : tout simplement ton eau courante.

            Toi t'as le front-end chez toi : c'est ta baignoire. Tu peux la changer, prendre celle qu'il te faut/qui te plaît, du moment qu'elle est correctement faite pour causer à la partie intermédiaire (qu'elle a la bonne taille de tuyau).
            La partie intermédiaire c'est les tuyaux dans toute la France tout ça.
            Et enfin le back-end, c'est la boite qui va te fournir en eau, et là aussi tu peux en changer (enfin c'est pas possible en France je crois mais bon). Pour toi c'est transparent : en dehors d'en choisir un, tu cherches pas à savoir comment il a branché tel truc sur tel machin pour que l'eau coule.

            On peut faire un peu la même (en mieux je trouve) avec le téléphone.

  • # GNUstep

    Posté par  (site web personnel) . Évalué à 3.

    A noter le support de cairo pour GNUstep, présent depuis assez longtemps dans le dépot.

    http://svn.gna.org/viewcvs/gnustep/libs/back/trunk/Source/ca(...)

    • [^] # Re: GNUstep

      Posté par  (site web personnel) . Évalué à 3.

      Et pour ceux qui poseraient la question "quand est-ce que KDE va l'utiliser ?" ou "si Qt l'utilisait aussi, ce serait top", je vous informe que Qt possede un moteur de rendu qui fait exactement la meme chose que Cairo, mais qui s'appelle Arthur. Export SVG, rendu sur OpenGl, export PDF via backend d'impression, etc etc.

      • [^] # Re: GNUstep

        Posté par  . Évalué à 1.

        Tu es sûr de toi pour l'export SVG ?

        Je n'en ai pas trouvé trace là: http://doc.trolltech.com/4.2/qt4-arthur.html

        Même si ça n'existe pas, c'est de toutes façons pas très dur à implémenter. Ça viendra vite si quelqu'un est intéressé...

        Une autre question, est-ce que c'est dépendant de Qt, ou bien est-ce que les dépendances sont plus légères, comme cairo ? (fontconfig et libpng si je me souviens bien).

        • [^] # Re: GNUstep

          Posté par  . Évalué à 4.

          Ceci dit, si les performances et les fonctionnalités de cairo et d'arthur sont équivalentes, alors oui ça serait vraiment super qu'on puisse converger vers une solution commune.

          Un peu comme dbus, quoi.

          • [^] # Re: GNUstep

            Posté par  (site web personnel) . Évalué à 2.

            Justement parce que les fonctionnalites sont equivalentes, ce n'est pas possible d'envisager une convergence. Ca voudrait dire que l'un des deux projets doit abandonner son moteur, ce qui est inenvisageable. Je ne vois pas Gtk se mettre a dependre de Qt et je ne vois pas Trolltech adopter une technologie externe alors qu'elle a tant investi sur X et Qt.

            A noter que ce n'est pas un probleme, Qt et Gtk coexistent depuis des annees sans problemes. Un minimum de diversite, quand il rime avec qualite a du bon.

            Pour dbus, on note son arrivee dans Qt 4.2 :
            http://doc.trolltech.com/4.2/qtdbus.html

  • # Précisions conçernant Firefox

    Posté par  (site web personnel, Mastodon) . Évalué à 10.

    Elle est ou sera utilisée par un nombre croissant d'applications, comme par exemple librsvg, Mono ou les prochaines versions stables de Firefox


    Cairo est déjà utilisé dans Firefox 1.5 pour afficher le SVG ou la balise canvas, le reste (affichage HTML, XUL &co) étant pris en charge par la bibliothèque graphique propre à gecko. Ce sera encore le cas pour Firefox 2.0 puisqu'il s'agira de la même version majeur de Gecko (1.8.x). Par contre, dans Firefox 3.0 (Gecko 1.9), cairo sera enfin utilisé pour tout affichage (HTML, XUL, SVG, etc..). Et vu les possibilités du backend Cairo, on pourra parier pour un meilleur résultat d'impression, un export PDF des pages html etc...

    Et au passage, il y a une refonte de la partie "layout" dans cette version 1.9 (le truc qui en gros, commande l'affichage d'un document HTML/XML à partir de styles CSS), qui permettra à gecko de passer le test acid2 (ce qui est en fait déjà le cas sur une branche de développement du moteur, cf http://ljouanneau.com/blog/2006/06/06/570-gecko-passe-le-tes(...) ).

  • # En plus

    Posté par  (site web personnel) . Évalué à 3.

    On peut aussi noter l'arrivée d'un backend directfb et d'un backend BeOS.
    Qui permet (en tout cas pour directfb), d'avoir gtk dessus sans trop se casser la tête.
    On peut noter aussi que webkit (port de khtml en gdk) fonctionne, ce qui permet d'avoir un browser complet(du point de vue rendu) "natif" directfb (càd sans avoir recours à un serveur X (rootless ou non))

    • [^] # Re: En plus

      Posté par  . Évalué à 4.

      > On peut noter aussi que webkit (port de khtml en gdk)
      Tu es sûr ?
      Il me semble plutot que WebKit est une surcouche de WebCore (port de KHTML pour Cocoa) pour l'utiliser en Objective-C++ intégré à l'api de cocoa

      Pour GTK, il y a ce projet qui a l'air mort:
      http://gtk-webcore.sourceforge.net/

      • [^] # Re: En plus

        Posté par  (site web personnel) . Évalué à 2.

        Effectivement je me mélange completement les pinceaux
        For those interested the initial port of webkit the safari html widget
        derived from KHTML on gdk is checked into Apple's svn.
        Its been tested under gdk-directfb of course :)
        [...]
        The sample launcher is in
        WebKit/WebKitTools/GdkLauncher
        [...]
        Start at.
        http://webkit.opendarwin.org/

        Mike

        Voila la moelle du mail de la mailing list
        http://mail.directfb.org/pipermail/directfb-dev/2006-July/00(...) Pour le mail complet
        Bon donc je sais toujours pas trop ce qu'est webkit par rapport à webcore, mais en fait le port est inclut dans leur arbre subversion, mais je retrouve pas dedans
        donc je sais que ca a l'air de marcher mais que je sais pas comment on accede aux sources ....

Suivre le flux des commentaires

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