Deux nouveaux lecteurs SVG

Posté par  . Modéré par Nÿco.
Étiquettes :
0
9
sept.
2003
Mozilla
On dirait que personne n'a relevé l'info, pourtant le site du W3C annonce la disponibilité de deux viewers SVG.

La preview de la version 6 du viewer SVG d'Adobe est compatible Mozilla (après l'installation, ne pas oublier de copier les fichiers NPSVG6.dll et NPSVG6.zip dans le dossier Plugins). Cette preview est assez bugguée au niveau du support de Javascript, mais en attendant la version finale, cela permet de profiter de SVG avec Mozilla (sous Windows certes... ;)

Chez Corel, c'est la version 2.1 pour Windows (IE et Netscape) qui sort.

Ces deux lecteurs sont propriétaires, mais le SVG est un standard du W3C qui remplace des solutions propriétaires d'animations de graphiques vectoriels sur le web.

Aller plus loin

  • # Re: Deux nouveaux lecteurs SVG

    Posté par  . Évalué à 4.

    Il me semble que c'est uniquement pour windows, non ?
    Alors, intérêt de la news ici ?
    Quand il y aura du neuf coté Linux, cela sera une vraie bonne nouvelle.

  • # Re: Deux nouveaux lecteurs SVG

    Posté par  . Évalué à 3.

    Mozilla bosse sur l'intégration du SVG.
    http://www.mozilla.org/projects/svg/(...)

    C'est 'already pretty useable' , qu'ils disent

    • [^] # Re: Deux nouveaux lecteurs SVG

      Posté par  . Évalué à 1.

      Sous windows et encore.
      Sous linux il n'y a pas de support pour ce qui limite tout de suite beaucoup.

      • [^] # Re: Deux nouveaux lecteurs SVG

        Posté par  . Évalué à 2.

        Y a pas Amaya qui sait créer / lire du SVG ?

      • [^] # Re: Deux nouveaux lecteurs SVG

        Posté par  . Évalué à 1.

        Tu as testé le binaire linux qu'on trouve dans la page ?

        • [^] # Re: Deux nouveaux lecteurs SVG

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

          Hum ... le lien est mort, et sauf erreur de ma part ca fait un bout de temps que les build svg linux ne sont plus faits.

          • [^] # Re: Deux nouveaux lecteurs SVG

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

            Pour gentoo, ya une variable USE a régler ... mozsvg je crois ... tout comme il est possible de compiler moz avec ou sans composer (moznocomposer) ou sans client mail (moznomail), etc ...

            • [^] # Re: Deux nouveaux lecteurs SVG

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

              yep, mais sauf si le branche dédiée aux corrections a fusionnée (je ne le crois pas mais c'est à vérifier), compiler avec SVG donnera un résultat dégeulasse (comprendre "à peine croyable") si tu as une profondeur d'écran de 24bits (ou un "faux" 32 bits qu'il y a avec quelques serveurs X). Comme c'est une donnée qui commence à être très courante ....

              Bref, y'a le SVG mais c'est probablement celui qui est pourri chez la moitié des gens et qui crash à certains tests officiels du W3C chez les autres.

  • # Re: Deux nouveaux lecteurs SVG

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

    Je veux bien que Flash ne soit pas un standard mais Flash est un format ouvert, certainement pas une technologie propriétaire fermée.

    http://www.openswf.org/(...)

    Certe les sepcs sortent en meme temps que la nouvelle version du format mais en aucun ca il s'agit d'une technologie fermée.

    • [^] # Re: Deux nouveaux lecteurs SVG

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

      Mais le plugin et l'édteur flash sont propriétaires, ce qui complique grandement la lecture et la création de sites flash. Par conséquent, tant qu'à développer un truc libre, autant s'intéresser au SVG+SMIL+un_langage_de_script, qui est nettement plus intéressant à terme. Non ?

      (Oui, il y a aussi toute la base existante de documents flash. Mais des gens bossent là dessus non ? Car avec gstreamer j'arrive à lire certains documents flash)

    • [^] # Re: Deux nouveaux lecteurs SVG

      Posté par  . Évalué à 7.

      Certe mais le format swf et asser lourd à mettre en place, son language de script est fortement bugger, sa structure de données et bordelique à souhait et ces possibilité de gestion de contenue dynamique son ridicule (même en utilisant generator qui en plus présente une licence hors de prix).
      De plus aucun soft ne permet de crée du flash sous linux correctement et cela - bien que possible - n'est pas près d'arriver.

      Tout cela changera peut-être avec leurs "nouvelles" version de studio MX 2004, mais très franchement je préfèrerai voir les linuxien utiliser/développer un standart complètement ouverts et non-contrôler par une grosse boite (Macromédia). Sachant que rien ne les empêchent un jour ou l'autre de fermer le format .. Pratique que le grand partenaire de macromédia à appliqué il y a peu avec Microsoft Messenger.

      Le SVG s'est bon mangez en !

      Ces possibilité sont alèchante, le format et beaucoup plus propre et pratique à utiliser que flash en dehors du seul domaine de l'animation (type dessin animé) images par images. Position qui en plus vas changer avec les prochaines recommandation w3c pour svg 1.2 voir maximum svg 1.3.

      Ceci est un appel : Linuxien, Linuxienne, codeur et fou de script siouplet developper un bon plug-ins pour svg sous linux !! Ou aider les codeurs de mozilla-svg pleeaaase .. (et si il vous reste du temps un p'tit soft wysiwyg serait pas mal non plus :-) Je suis web-developper et j'en ai marre de ne pas pouvoir utiliser ce format ouvert sous linux correctement :(

      Ok je vais pleurez ailleurs --> []

      • [^] # Re: Deux nouveaux lecteurs SVG

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

        Pour le soft WYSIWYG, Sodipodi utilise le SVG comme format par défaut. Je ne sais pas si c'est du SVG "conforme", c'est à dire s'il marche avec des trucs comme le plugin d'Adobe, mais en tout cas c'est un bon début.

        Par contre c'est du SVG tout seul, pas de langage de script, pas de SMIL, donc en aucun cas un concurrent à flash.

        • [^] # Re: Deux nouveaux lecteurs SVG

          Posté par  . Évalué à 2.

          Oui, je dirait que sodipodi "concurence" des logiciel comme sketch ou Illustrator sur la tranche "dessins vectoriel".

          Il serait sympas de voir un projet se ratacher à sodipodi pour ajouter des tools box pour le script, l'animation etc...

          • [^] # Re: Deux nouveaux lecteurs SVG

            Posté par  . Évalué à 1.

            Il me semble que l'animation est la direction vers laquelle se dirige l'équipe de développement (réduite) de Sodipodi.

      • [^] # SVG/SWF

        Posté par  . Évalué à 8.

        Certes mais le format SWF est assez lourd à mettre en place

        Lourd ? Le plugin de macromedia fait environ 1Mo. Le plugin SVG d'Adobe fait plus de 4Mo.
        Si tu veux parler de la lisibilité du code, alors je t'arrète tout de suite : les graphistes ne travaillent pas avec des éditeurs de texte sur des fichiers PostScript, de même que les web designers ne travailleront jamais directement à la main sur des fichiers SVG.

        son language de script est fortement bugger,

        Fortement buggé est exagéré. Il y a des bugs certes, et c'est frustrant qu'on ne puisse pas les corriger soi-même.

        sa structure de données et bordelique à souhait

        Comme je disais, il n'y a aucune chance que les designers travaillent directement sur des fichiers textes, ou, dans le cas du SWF, binaires. A moins que le SVG n'apporte des avantages réellement spectaculaires par rapport au SWF, ce qui n'est, à mon avis, pas le cas.

        ses possibilités de gestion de contenu dynamique sont ridicules

        Ridicule ? Ridicules les sockets XML, le protocole AMF (utilisé par le Remoting) et le classique LoadVars ? C'est justement un des gros points forts de Flash : on n'est pas prisonner de la perte d'état lié à HTTP (plus besoin de variables de session, etc).

        même en utilisant generator qui en plus présente une licence hors de prix

        Personne avec la moitié d'un cerveau n'a jamais utilisé Generator. Il y a toujours eu des alternatives, toujours gratuites, et maintenant Libres avec la librairie Ming.

        Je serais très très content de voir SVG se développer, mais il faut bien se rendre compte qu'il y a aujourd'hui beaucoup, beaucoup de chemin à parcourir. Amen.

        • [^] # Re: SVG/SWF

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

          "... de même que les web designers ne travailleront jamais directement à la main sur des fichiers SVG"
          Pourtant je connais bcp de web developers qui travaillent directement à la main sur des fichiers (X)HTML, alors pourquoi pas sur des finiers SVG? Non là je ne suis pas d'accord avec toi, et meme si c'est la majorité, il faut à mon avis encourager la methode à la main.

          Dites le moi si je me trompe, mais les fichiers flash ne se basent pas sur de l'XML n'est ce pas?
          Pour moi, l'avantage de SVG c'est qu'il est lui basé sur une structure XML!
          Ca laisse entrevoire de belles combinaisons à la sauce XML->[XSLT processor]->SVG ou bien encore XML->[XSLT processor]->XHTML+SVG.
          Et ca AMHA c'est la panacée. En plus, on peut noter que les browsers commencent à integrer des processeurs XSLT (Gecko et IE6). Cela permettant d'eviter les transformations coté server via servlet+xalan/saxon par exemple.

          • [^] # Re: SVG/SWF

            Posté par  . Évalué à 1.

            Pourtant je connais bcp de web developers qui travaillent directement à la main sur des fichiers (X)HTML, alors pourquoi pas sur des finiers SVG? Non là je ne suis pas d'accord avec toi, et meme si c'est la majorité, il faut à mon avis encourager la methode à la main.

            mouaip... dans les boîtes que j'ai faites, y avait 2 types de personnes:
            - les développeurs des sites qui voulaient du fonctionnel et la maîtrise de leurs développements (donc eux, ils mettent la main dans le cambouis)

            - les "artistes", ceux qui utilisaient flash (entre autre) et eux par contre n'ont aucune compétence en dév , ils se contenent d'utiliser des outils qui permet de développer leurs créations.
            Et pourquoi devraient ils se prendre pour des développeurs ?
            C'est comme demandé à un guitariste d'avoir des compétences de luthier.

            • [^] # Re: SVG/SWF

              Posté par  . Évalué à 1.

              > pourquoi [les créatifs] devraient ils se prendre pour des développeurs ?
              Parce que c'est web dev, pas dev. On ne leur demande pas de faire un programme, mais de faire une structure de présentation. Ils devraient connaître un peu le HTML, la structure, la nécessité d'une normalisation, etc. En fait, pour moi, le créatif devrait juste s'occuper de la CSS, [cf. http://csszengarden.com(...)] le contenu étant affaire de quelqu'un qui comprend les enjeux.
              Mais bon. Rome ne s'est pas faite en un jour, les méthodes ne changent pas facilement.

              > comme demander à un guitariste d'avoir des compétences de luthier.
              Beuh? faut pas pousser mémé dans les lianes, ni les comparaisons.

              En même temps, je suis d'accord avec toi, c'est la situation actuelle, mais il faut garder une lueur d'espoir.

    • [^] # Re: Deux nouveaux lecteurs SVG

      Posté par  . Évalué à 2.

      Dans un univers ou il y a des eucd-dmca et des brevets logiciels qui nous pendent au nez/qui sont déja une réalité pour d'autres, un format aux specs ouvertes ne suffit pas, surtout quand il est l'oeuvre d'une société qui utilise constament les brevets dans sa lutte contre adobe, qui d'ailleurs n'est pas en reste de ce coté là non plus et ne répugne pas non plus à utiliser le dmca pour attaquer des développeurs.

    • [^] # Re: Deux nouveaux lecteurs SVG

      Posté par  . Évalué à 2.

      "Disponible" et "ouvert", ou encore "non-propriétaire" sont des choses différentes qu'il s'agit d'utiliser correctement.

      La spec SWF est disponible, elle peut être lue par qui veut implémenter SWF.

      Enfin presque. Le EULA est très restrictif. Par exemple quelqu'un qui travaille sur un produit potentiellement concurrent (eg kSVG) n'a pas le droit de lire la spec. Hmm, je n'appelle pas ça très ouvert...

      Aussi, ils disent très clairement que si leur propre viewer diffère de ce qui est dans la specification, c'est leur viewer qui a raison et non cette dernière, et toute implémentation de la spécification doit suivre le viewer (donc comprendre ses bugs et les imiter) sous peine de poursuites. Hmmmm, il semblerait que ce ne soit pas vraiment une spécification alors...

      Et bien entendu, c'est une techno purement propriétaire.

      En bref, SWF est disponible à certains, fermé, et propriétaire. Ca arrange Macromedia d'appeler ça "open" pour des raisons marketing, mais il ne faut pas tomber dedans. Pour avoir suivi de près tout ce qu'ils ont déployé d'effort et de crasses pour empécher l'avènement de SVG, ils ne m'inspirent pas beaucoup plus de respect que cette autre société dont le nom commence aussi par un "M"...

  • # Re: Deux nouveaux lecteurs SVG

    Posté par  . Évalué à 3.

    Personnellement, j'aime bien Batik d'Apache (http://xml.apache.org/batik/index.html(...))
    c'est écrit en Java, c'est développé sous license Apache.

    Si vous voulez tester rapidement, suivez le lien Webstart:
    http://nagoya.apache.org/batik_1.1/batikNagoya.jnlp(...)

    Syj.

    • [^] # Re: Deux nouveaux lecteurs SVG

      Posté par  . Évalué à 3.

      Effectivement, le résultat est assez impréssionnant et montre les possibilités du SVG en ce qui concerne le graphisme 2D !
      Dommage que ça soit "lent" et que ça ne puisse pas être intégré dans un browser (mozilla, konqueror...)

  • # Re: Deux nouveaux lecteurs SVG

    Posté par  . Évalué à 5.

    c'est simple. malgré les apparences flash est controlé uniquement par macromédia. ce qui est un probleme.

    SVG en plus d etre une norme w3c et raisonnablement exonoré de brevets (donc une implémentation totale des specs svg en opensource est possible) et basé XML, ce qui a terme permet d'intégrer la gestion et création de document SVG depuis n'importe quel outil XML /base de donnée xml

    cela peut paraitre inutile a premiere vue mais en fait permettre des applications non encore imaginés

    de plus, SVG est aussi modifiable (du coup) par DOM, naturellement, comme tout document XML. en fait, vient tout une convergence de méthode qui a terme simplifiera la vie du
    -developpeur de soft xml /edition web
    -webdesigner qui se concentrera à comprendre les technologies XML et non plusieurs concepts alien
    -de l'utilisateur linux ou win ou osx qui utilisera le soft de son choix reposant des normes ouvertes à tous (propriétaires, ouvert, commerciaux, gratuits, etc)

    Que Adobe donne un coup de pied a la montagne flash de macromedia est aussi une bonne chose pour nous en tant que clients, adobe et macromedia vont se battre a coup de qui fait la meilleur techo et les meilleurs prix
    de plus meme si adobe aura les moyens de proposer des outils extrement puissants (mais propriétaires) avec svg, les "logiciels libres/opensource" auraont aussi plus de latitude pour proposer de beaux outils svg.

    je rejoins par contre les sceptiques pour evidemment souligner qu'il y a encore un boulot monstre à fournir.

    • [^] # Re: Deux nouveaux lecteurs SVG

      Posté par  . Évalué à 1.

      c'est simple. malgré les apparences flash est controlé uniquement par macromédia.
      Comme PDF par Adobe non ? Ah oui mais non, là on a des implémentations potables sous Linux, donc c'est bon on s'en fout. Faut croire que le contrôle du format n'est pas le fond du problème...

      • [^] # Re: Deux nouveaux lecteurs SVG

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

        Adobe a toujours eu une attitude très correcte quant au respect des standards qu'il a publié, que ce soit le Post-Script ou le PDF.
        On ne peut pas en dire autant de certains éditeurs comme Microsoft.
        D'ailleurs ce point est peut être à exploiter : si Microsoft est certifié ISO9000, ce serait un cas de radiation.
        Rappel : ISO9000 c'est « écrivez ce que vous faites et faites ce que vous écrivez ».

Suivre le flux des commentaires

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