Journal Point sur le format SVG

Posté par (page perso) .
Tags :
13
12
déc.
2009
De temps en temps, je regarde, en priant, que le support SVG dans les navigateurs s'améliorent...
Et, c'est toujours la même chose, ou presque: il y a donc Opéra[1]
Et derrière, le reste : Adobe SVG Viewer(qui n'est plus supporté), Webkit[2], FireFox[3],... (pas forcement dans le bon ordre)

J'espère que quelqu'un ici pourra parler du support d'Amaya et de Bantik, car pour ma part, je me suis arrêté à cette page[4].

D'ailleurs sur cette page, on s'aperçoit que pour faire du SVG un minimum compatible, ça va être la lutte (avec des bons gros hacks !)
Voilà, qu'il y a un an environ, un nouveau projet arrive svgweb[5] et le but de ce projet est de faire... du SVG dans du flash.
Ce projet avance vite et marche bien en plus. Mais ressemble, pour moi, à ce qui est le paroxysme de la débilité du web !
Je ne dis pas ça, contre ce projet, qui je pense à le mérite de faire avancer les choses mais je trouve fou dans arriver là par un manque de cohérences et de concertations.

La norme doit dater de 2001, si je ne me trompe pas, et elle n'est toujours pas d'actualité dans nos navigateurs...
De plus, quand je vois qu'Inkscape fait son propre SVG[6] pour pouvoir intégrer des manques à la norme initiale, je me demande qu'elle est le futur du SVG.

Je voulais avoir votre avis et des éclaircissements.

[1] http://www.opera.com/docs/specs/svg/
[2] http://webkit.org/projects/svg/status.xml
[3] http://www.mozilla.org/projects/svg/status.html
[4] http://en.wikipedia.org/wiki/Comparison_of_layout_engines_(S(...)
[5] http://code.google.com/p/svgweb/
[6] http://wiki.inkscape.org/wiki/index.php/InkscapeSVG
  • # http://www.codedread.com/svg-support-table.html

    Posté par . Évalué à 7.

  • # batik

    Posté par . Évalué à 2.

    Batik n'est pas un browser, c'est une bibliothèque en java (de la fondation apache) pour gérer le SVG (y compris l'aspect scripting)
    Tu peux voir là
    http://xmlgraphics.apache.org/batik/status.html
    l'état du support du SVG 1.1
  • # W3C validator

    Posté par . Évalué à 4.

    D'ailleurs sur cette page, on s'aperçoit que pour faire du SVG un minimum compatible, ça va être la lutte (avec des bons gros hacks !)

    Il y a quelques temps je voulais me mettre au svg. Ne trouvant pas de documentation suffisante sur le net j'ai acheté le livre SVG de la collection O'REILLY.

    Et bien même avec le livre je me suis bien embêté pour rendre ma pauvre page valide xhtml1.1 strict ! Je ne sais pas ce que ça donne avec l'html 5 et ses nouvelles balises.
  • # svgweb

    Posté par (page perso) . Évalué à -2.

    tu peut dès aujourd'hui faire en sorte que TOUS les navigateurs supportent le svg grace à une petite bibliothèque javascript. J'en avais déja parlé ici : http://linuxfr.org/comments/1061282,1.html et j'ai traduit en français (mal) le guide de démarrage rapide ici : http://yohanng.blogspot.com/2009/08/guide-de-demarrage-rapid(...)

    Pour ceux qui ont la flemme de lire , l'idée de svgweb est de traduire ton svg en flash pour les navigateurs qui ne supportent pas le svg ( ou mal)
    • [^] # Re: svgweb

      Posté par . Évalué à 8.

      L'information est indiquée dans le journal.

      Par ailleurs, si on traduit le svg en flash, « TOUS » les navigateurs ne supportent pas les svg : seuls ceux sur lequel est installé un plugin flash peuvent l'utiliser.

      Perso, je préfère une image SVG (que je peux lire) à une animation flash (que je ne peux visualiser).
      • [^] # Re: svgweb

        Posté par . Évalué à 3.

        moi aussi, mais je pense que ce projet à l'intérêt de pouvoir permettre de mettre en avant le SVG, en encourageant les développeurs à l'utiliser, par exemple dans le cas d'un intranet où le client ne veut pas migrer ses navigateurs type IE6 vers un navigateur compatible, ou pour un site si on peut détecter que le svg ne passe pas, cela lance la version flash.

        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

      • [^] # Re: svgweb

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

        le rendu flash n'est utilisé que par les navigateurs ne le supportant pas. Sur opera par exemple, tu n'aura pas de rendu flash mais un rendu SVG que tu pourra donc lire.

        le but du projet n'est pas, comme l'indique le journal de faire du svg dans du flash mais de permettre l'adoption de svg dans le web .

        Suit un peu mon raisonnement, puis-je en tant que webdéveloppeur me permettre d'intégrer une technologie supportée par Un seul navigateur ? Donc pour faire de l'animation, je vais me tourner vers une autre technologie (flash par exemple) qui bénéficie d'une assise suffisante en terme de % utilisateurs.

        SVGweb me permet d'intégrer du svg dans mes sites et de profiter du flash quand (et seulement quand) le support svg du navigateur est nul ou mauvais.

        Je ne trouve pas que c'est la "débilité du web" c'est du pragmatisme et ça me permet de faire du SVG dès maintenant.

        Enfin, et c'est justement le but de ce genre de bibliothèque, plus il y aura de site svg, plus les navigateurs tendrons à le supporter, et le supporter de mieux en mieux.

        quand à inkscape, en lisant le lien donné par le journal on trouve :

        standards-conforming (the SVG standard permits these kinds of extensions)
        (donc on reste standard)

        inkscape svg is basically the same as plain svg, just with a couple of extra commands (in seperate namespaces) added, which the inkscape tools use to keep track of their work.

        donc très clairement un espace de nom pour la tambouille inkscape, pas un "nouveau svg",

        c'est standard, c'est autorisé par la norme, on peut même s'en passer, on peut l'ouvrir dans un autre éditeur sans modification de l'affichage.

        De plus, le but d'inkscape est clairement indiqué dans le roadmap (http://wiki.inkscape.org/wiki/index.php/Roadmap#Inkscape_Dev(...)

        Inkscape 1.00 - Full SVG 1.1 support

        Le but d'inkscape est donc d'être 100% standard.

        alors quand je lit : De plus, quand je vois qu'Inkscape fait son propre SVG
        c'est de la mauvaise foi ou du moquage de bouche
        • [^] # Re: svgweb

          Posté par . Évalué à 2.

          c'est de la mauvaise foi ou du moquage de bouche

          je pense que l'auteur n'a pas bien lu le lien qu'il pointait (vu qu'il semble par ailleurs favorable au svg), et honnêtement, étant utilisateur de inkscape, je pensais également que le format svg d'inkscape était beaucoup plus modifié que cela (j'ai découvert que ce n'est pas le cas justement en lisant ce lien). Donc c'est plutôt une bonne nouvelle, par contre c'est vrai que, comme j'ai dit dans un autre commentaire (dans le journal sur sozi), même dans les divers projets libres d'éditeurs svg, à l'époque où j'en avais testé plusieurs, il y avait de grosses différences d'interprétations d'un éditeur à l'autre. (peut-être que cela s'est lissé maintenant, mais je n'ai pas retesté, utilisant principalement inkscape)

          Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it

        • [^] # Re: svgweb

          Posté par . Évalué à 1.

          Inkscape rajoute surtout des données permettant de remodifier un élément pouvant être crée facilement depuis inkscape.

          Par exemple: une spirale, il n'y pas de norme dans le SVG permettant de faire une spirale d'après des données mathématiques et la spirale apparait comme un chemin dans un svg. Inkscape rajoute dans le svg ces données permettant ainsi de rééditer facilement la spirale par la suite. On se retrouve donc avec un svg avec le chemin de la spirale et les données permettant de la modifiée facilement.

          Le problème intervient quand un autre éditeur modifie le SVG. Doit-on lire le chemin de spirale ou les données mathématique pour déssiner la spirale dans inkscape ?

          Je rappelle que inkscape enregistre par défaut dans ce format mais propose aussi d'exporter dans un SVG standard.
  • # Oh non !

    Posté par . Évalué à -9.

    Oh non pitié pas du SVG, ça suffisait pas flash pour mettre un PC à genoux ? Et après on parle d'informatique verte ...

    J'veux bien croire que ça puisse être utile, mais au final ça va être comme flash, ça va être complètement inutile dans 99% des cas ou c'est utilisé, mais il faudra quand même se le farcir puisqu'il restera toujours des sites webs incontournables qui seront inutilisable avec SVG désactivé, vu qu'ils seront codés par des développeurs idiots qui ne pensent qu'a eux ...

    Et puis je vois vraiment pas pourquoi il faudrai du vectoriel sur le net, y a déjà plus de la moitié des sites webs qui n'ont même pas de design liquide, alors à quoi ça sert d'avoir du vectoriel avec une taille fixe ?

    J'espère pas avoir besoin un jour d'un plugin SVGBlock, mais si ça deviens nécessaire, je suis prêt à la coder si ça n'existe pas déjà.
    • [^] # Re: Oh non !

      Posté par . Évalué à 6.

      Le SVG c'est du XML. J'ai du mal à imaginer comment du XML peut t'alourdir la machine XHTML c'est aussi du XML et je ne pense pas que ce soit plus lourd qu'autre chose.

      Pour l'animer c'est du javascript, là aussi on utilise du javascript de puis 15 ans sur le web et même si c'est souvent à tord et à travers c'est régulièrement utile.

      Pour ce qui est de l'utilité du SVG c'est très simple. Quand tu génère des images de manière automatique tu peut faire de manière très simple pour du SVG. Prenons le cas de mozilla. Lors de la sortis d'un logiciel ils créent des dizaines de versions d'une même image avec juste la langue qui change pour mettre sur leur site. Avec SVG tu peut changer dynamiquement le texte de manière simple.

      Autre utilisation c'est bien sur google, avec google map quand tu demande un itinéraire le tracé est dessiné en SVG pour les navigateurs compatibles (en un autre format vectoriel pour IE d'ailleurs).

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: Oh non !

        Posté par . Évalué à 4.

        oui, mais non, c'est pas parce que xhtml et svg utilisent le meme langage de description que c'est la meme chose.
        Et c'est pas parce que flash est binaire et svg texte que le deuxieme va etre un foudre de guerre.

        SVG utilise pour faire ce que fait flash aujourd'hui, a savoir des applis riches, ca va faire pareil que flash a ton cpu: ca va monter dans les tours tres vite.
        Parce que de toutes facons, c'est manipule via le meme langage (ou sensiblement le meme), javascript. et que ca sera le meme genre de code qui tournera, donc ya pas de raison que svg soit magiquement 10x plus rapide, sachant qu'adobe a deja fait un travail plus que raisonnable sur sa vm AS.

        Bref, l'avantage c'est que ca sera ouvert, mais d'un point de vue perf, meme combat.
        • [^] # Re: Oh non !

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

          Mais qu'est-ce que vous racontez?

          La norme SVG prévoit qu'il soit animé, mais pas par javascript uniquement. Actuellement, la seule maniere d'animer du svg est de modifier le xml dynamiquement en javascipt (beurk) parce que les programmeurs des navigateurs oueb ne se sont pas sorti les doigts du cul, mais ça peut être implémenté en C ou n'importe quoi d'autre.

          En respectant les balises, ça permettrait aussi de compiler l'animation juste a temps, comme ce qui commence à se faire avec javascript, et gagner énormément en performances.

          L'ultime problème est qu'on ne peut pas encore facilement faire d'animations en SVG. Mais Inkscape prévoit la création d'animations dans quelques versions. Alors gageons que ce sera une autre paire de manches!
          • [^] # Re: Oh non !

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

            je crois que l'autre standard prévu pour les animations c'est SMIL. L'un des avantage de SVGWEB est justement de permettre de déja faire du svg + smil et c'est assez sympa d'un point de vue développeur.
            • [^] # Re: Oh non !

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

              Oui c'est SMIL qu'il te faut, et c'est déjà dispo dans Opera (et c'est cool), dans webkit depuis peu aussi je crois. Dans FF ça y sera dans un an je crois (FF3.7 ?).

              Sinon niveau "ça rame" il va y avoir bientôt les CSS transitions et animations, créées par webkit et bientôt dans gecko et Opera. J'espère qu'on pourra désactiver ça parce que ça promet d'être relou...

              « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

          • [^] # Re: Oh non !

            Posté par . Évalué à 1.

            Certes, tu peux faire du jit.
            Et qu'est ce que tu crois que le player flash fait, si ce n'est du jit? Et ca bouffe du cpu.

            Quand a l'implementer en C, c'est un peu a l'oppose de la philosophie du web, bon courage pour deployer ton anim svg...
      • [^] # Re: Oh non !

        Posté par . Évalué à 2.

        Alors la on fait fort, dire que le SVG c'est juste du XML, on me l'avait jamais faite.
        le SVG c'est du vectoriel, et le vectoriel, c'est lent, tout comme flash. Tu trouve peut être super le fait d'avoir des freezes quand on va sur google maps (ou dès que quelqu'un inclut un google maps quelque part), mais moi pas, surtout sur une config moyenne de maintenant. Faudrai peut être se demander pourquoi flashblock existe. En tout cas il existera un svgblock quand demain toutes les pubs soient en SVG animé et quand ça sera la mode des menus, des bandeaux et des smileys en SVG animé. Faudra pas venir parler d'informatique verte après.

        Quand à javascript, il existe depuis 15 ans, mais il aura fallu combien de temps avant qu'on se soucie de son optimisation ? Quand Ajax est (re)devenu à la mode, les PC d'entrée de gamme étaient tous à la ramasse, avec une navigation pas du tout fluide, tout ça pour soit disant "améliorer la navigation".

        C'est sur, ça peut être utile, mais dans le cas du texte qui change c'est pas le cas. On n'a pas besoin de vectoriel juste pour pouvoir changer du texte, on peux déjà le faire avec du bitmap des grands mères et du CSS de grand père, c'est peut être moins simple, mais ça marche mieux avec les vieux navigateurs (et les smartphones, accessoirement). Et franchement, je m'appellerait mozilla, je commencerai déjà par faire un site web utilisable quand on zoome le texte avant de m'amuser a mettre du vectoriel dans un bloc de taille fixée en pixels.
        • [^] # Re: Oh non !

          Posté par . Évalué à 3.

          Comme je le dis plus haut non le vectoriel c'est pas si lourd que ça. D'une part le fichier est X fois plus léger que la même version dans un format bitmap. D'autre part il y a des visionneurs d'images (eog ou mirage par exemple) qui font ça sens sourciller. Je vois pas pourquoi ça serait plus lourd une fois embarqué dans un navigateur.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Oh non !

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

            en fait, et bien que je soit un fervent défenseur de SVG ( qui ne sert pas, loin de la) qu'au web, faudrait il le souligner, c'est à partir du moment ou sa bouge.

            Le svg ce n'est que du xml et si c'est sa force, c'est aussi sa faiblesse puisque le logiciel visionneur doit ( aretez moi si je me trompe ) se palucher tous les calculs. Donc plus un SVG contiens de nœud (et une police en contient beaucoup) plus il faut solliciter le proc. Après, si tu me met un svg à 12 millions de nœuds (c'est un exemple) mon navigateur va s'écrouler comme une m...

            Mais c'est aussi un faux procès : critique t'on le C parce que mal optimisé il peut mettre à genoux mon ordi ? Il y aura de mauvaises utilisations de svg dans le web et d'autres très belles, les utilisateurs trancherons.
            • [^] # Re: Oh non !

              Posté par . Évalué à 4.

              Nous sommes d'accord c'est un peu comme dire que bmp c'est nulle parce qu'on peut mettre des bmp de 12Mo sur une page et que c'est super lourd à charger.

              Faire un site en flash est une très mauvaise habitude et ça ne seras pas mieux en SVG. Ce sont des parties du site qui doivent être faites en SVG.

              Comme tout technologie il faut savoir l'utiliser avec parcimonie et réfléchir à son utilisation à chaque fois.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Oh non !

            Posté par . Évalué à 2.

            C'est sur que ça sourcille pas sur ton Quad Core Extreme Quartz Gold, mais chez moi ça fait 1 secondes avant que ça affiche quelque chose en plein écran, avec un simple athlon xp 2000, alors j'ai même pas envie d'essayer une animation. T'a déjà essayé une animation SVG sur un netbook ? sur un smartphone ?
            • [^] # Re: Oh non !

              Posté par . Évalué à 3.

              Pour ta gouverne j'ai deux ordinateurs :

              le premier fixe est à base de Celeron 441 2.6GHz (c'est du mono core sans hyperthreading)
              le second est un MSI Wind de la première génération (atom 270 donc 1.6GHz avec hyperthreading)


              Ben sur mon PC fixe ça bronche pas je dirais même qu'il met arrivé d'utiliser des « dock » avec du SVG de partout sans aucun souci.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # 2001

    Posté par . Évalué à 3.

    En 2001 quand ils ont sortis la norme ils ont pas sortie une bibliothèque en C qui en faisait la démonstration et qui serait libre de droit (genre licence BSD sans copyleft).

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Encore combien de temps ?

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

    J'aime beaucoup le principe du SVG. Décrire un dessin vectoriel en XML, avec la possibilité de l'animer avec du javascript, franchement, c'est super.

    Sauf que voilà, ça fait des plombes que ce format existe, et que ce n'est toujours pas répandu.
    En 2005, juste après mes études, j'ai bossé sur un projet qui consistait à automatiser la production des pages web du budget de l'État : http://www.performance-publique.gouv.fr/farandole/2010/pap.h(...)
    Dans ces pages vous pouvez constater :
    * que le rendu est moche (c'est du .doc converti en html)
    * que c'est compliqué de trouver quelque chose
    * que c'est très hétéroclite
    * et que c'est dépourvu de graphiques

    Pour les 3 premiers points, rien à voir avec le SVG. Concernant le dernier, j'en suis le premier désolé.
    Jeune et fou que j'étais, j'avais développé une extension à la bibliothèque JFreeChart [1] qui faisait en sorte de convertir les graphiques en svg grâce à Batik [2] (dont il est question dans ce journal) en les rendant interactifs avec du javascript.
    Par exemple, lorsque l'on passait la souris devant une portion d'un camembert, celle-ci s'agrandissait, et on pouvait cliquer dessus pour se rendre sur la page correspondant au détail.

    Ça marchait bien dans firefox et dans ie grâce à Adobe SVG Viewer (qui était encore maintenu, mais qu'il fallait installer comme plugin)

    J'avais naïvement espéré contribuer à l'essor de SVG.

    Sauf qu'aucun graphique n'a jamais été produit sur le site, ou alors avec autre chose que ma lib. Pourtant je vais vérifier presque tous les ans... Je me suis renseigné après coup, on m'a évasivement répondu qu'ils craignaient que ce ne soit pas lisible par les navigateurs, et voulaient s'épargner la maintenance sur ce point là.
    Aujourd'hui je ne peux que me dire qu'ils ont eu raison de ne pas se compliquer la vie avec, vu que c'est encore moins bien supporté dans ie (qui reste malgré tout le navigateur le plus représenté), et c'est supporté de manière non déterministe sur les autres.

    C'était il y a 4 ans, et j'ai l'impression que dans les navigateurs, la balise canvas évolue beaucoup plus vite alors qu'elle est arrivée bien après.

    [1] http://www.jfree.org/jfreechart/
    [2] http://xmlgraphics.apache.org/batik/
    • [^] # Re: Encore combien de temps ?

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

      SVG et canvas n'ont absolument pas la même finalité.

      Faut pas confondre document et API. http://ljouanneau.com/blog/post/2009/03/26/Differences-entre(...)

      De plus, canvas avance plus vite, normal, ce n'est qu'une surface de rendu avec des primitives graphiques de base. Absolument rien à voir avec la spec de SVG qui fait plusieurs centaines de pages. (et donc plus longue et plus complexe à implémenter).
      • [^] # Re: Encore combien de temps ?

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

        Je sais bien que svg et canvas n'ont rien à voir, mais dans un navigateur l'un et l'autre peuvent pourtant être utilisées aux mêmes fins.

        Ce n'était peut être pas bien mis en avant dans mon commentaire précédent, mais pour les charts tu peux les réaliser avec svg ou avec canvas, et dans les 2 cas les rendre interactifs.
        Pour l'utilisateur final, il n'y a pas de différence.
    • [^] # Re: Encore combien de temps ?

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

      Non non non on n'anime pas SVG en javascript ! De l'animation (que ça soit de CSS ou de SVG) en JS est un non-sens, c'est un langage asynchrone qui n'a aucune gestion de timeline, on ne peux pas sérieusement faire de l'animation avec. On anime du SVG avec SMIL, qui est conçu pour et marche très bien.

      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

Suivre le flux des commentaires

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