Forum Programmation.web passer de jpg à svg ?

Posté par .
Tags : aucun
6
23
nov.
2010
Bonjour,
Nous réalisons des graphes (courbes, camemberts, ...) à l'aide de la librairie en PHP jpgraph (version 1.14, même ma grand-mère est née après...) et je me demandais s'il n'était pas intéressant de passer à du SVG, ce qui aurait l'avantage de reporter une partie de la charge (génération de l'image) du serveur vers les clients Web.
Sauf que...
* les clients Web sont des clients légers (donc peu de patate sous le capot, je n'ai pas la config exacte mais je peux me renseigner) => temps de traitement du SVG ?
* les navigateurs actuels sont IE6, mais deviendront IE7 et IE8 dans quelques mois => support de SVG (que ce soit en natif ou via un plug-in) ?

Existe-t-il donc des comparatifs entre la génération d'une image en jpg (ou en png, si cela vaut le coup de changer juste de format) et le svg ?

Merci.
  • # JPG/SVG

    Posté par . Évalué à -1.

    tu es sur que la generation du SVG via PHP se fasse sur le client ?

    je ne dit pas si tu changes pour du javascript ou un langage qui va tourner sur le client,
    mais si tu reste en php, je penses que l'image JPG/PNG/SVG sera toujours generer par le serveur
    • [^] # Re: JPG/SVG

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

      Pour le svg, il parle du rendu. Générer le svg est très peu coûteux, puisque c'est un petit fichier texte avec des primitives graphiques de haut niveau. C'est le rendu qui est cher, et il est réalisé par le navigateur du client.

      Évidemment, l'inconvénient c'est que ce rendu va changer selon le navigateur du client...
      • [^] # Re: JPG/SVG

        Posté par . Évalué à 2.

        En effet, le but serait de déporter (une partie de) la charge de travail de génération de l'image sur les clients, sachant pertinemment qu'il restera toujours une partie du travail à faire sur le serveur pour générer le XML du svg.

        Pour les navigateurs, seuls IE6 (actuellement) et IE7/8 sont concernés (car ce sont les seuls navigateurs officiellement supportés chez le client). Si l'on passe par un plug-in (celui d'Adobe, par ex. ?), peut-on supposer avoir un rendu équivalent ?
        • [^] # Re: JPG/SVG

          Posté par . Évalué à 2.

          Oui, y'a un plugin d'Adobe pour le SVG. Jamais étudié ça de près, mais j'ai vu certains collègues afficher du SVG avec IE6 via ce plugin.

          C'est d'ailleurs très merdique, car le SVG ne s'affiche pas nativement avec un vrai navigateur. Faudra tester le User Agent et générer une page différente selon si c'est "IE6 + plugin" ou bien un navigateur Web correct.

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

          • [^] # Re: JPG/SVG

            Posté par . Évalué à 3.

            Il existe bien un plugin adobe mais qui n'est plus supporté depuis le 1er janvier 2009 comme d'ailleurs la plupart des autres boites qui fournissait aussi un plugin (corel par exemple).
            http://www.adobe.com/svg/viewer/install/
            L'arrêt du support m'a permis à l'époque d'imposer Firefox, tout bénéf dans mon cas ( mais bon petite structure)
            Il y a http://code.google.com/p/svgweb/ (ayant google pour contributeur) qui permet d'utiliser le plugin flash pour visualiser le svg.
            C'est en développement mais fonctionnel. Faut aimer le cumul avec Flash !
  • # PNG

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

    Je ne sais pas si le SVG dans IE est déjà assez mûr pour une utilisation en production, mais une chose est certaine: le format PNG est beaucoup plus adapté pour des graphes que JPG.
  • # Le merveilleux monde de l'entreprise

    Posté par . Évalué à 6.

    Je ne travaille pas dans l'informatique et j'aimerais comprendre comment ça marche. Pourquoi utilisez-vous IE 6, il y a un avantage particulier ? Comment un type à son bureau peut-il encore décider aujourd'hui « faisons notre nouveau site interne optimisé pour IE6 » ?

    De la même façon, pourquoi rester sur une ancienne version de la bibliothèque graphique ? cela coute-t-il si cher en temps de faire la mise à jour et éventuellement d'adapter le programme aux changements d'API ?
    • [^] # Re: Le merveilleux monde de l'entreprise

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

      De nombreuses grosses boites ont intelligemment optimisés leurs applications pour des bizarreries comme IE6. Au point que ces applications sont totalement inutilisables sur de vrais navigateurs.

      Ils se sont rués sur la moindre entorses aux normes que MS à pu gerber. Le résultat est un ensemble de truc immondes : les applications centrales de l'entreprise.

      Passer à IE7 ou pire IE8 représente des décennies de travail. Beaucoup plus que le temps d'écriture initiale : en effet plus personne ne sait comment cela fonctionne, à quoi ça sert...

      A chaque fois qu'on touche une virgule dans un fichier properties ou ini d'un serveur, 15 applications plus loin, la somme des crédit est égale au double des débits. Donc un seul mot d'ordre, n'y toucher pas !

      Par ailleurs, on a jamais de budget pour entretenir une application. Un camion, un bâtiment, une photocopieuse l'entretien est budgété, une application jamais. Ça ne doit pas vieillir !
      • [^] # Re: Le merveilleux monde de l'entreprise

        Posté par . Évalué à 5.

        Bertrand a bien résumé le problème.
        J'ajoute que des entreprises ont des applications « optimisées pour IE6 » qu'elles ont achetées et pour lesquelles la mise à jour soit coûte cher (achat de licences, migration,...) soit, pire encore, n'existe pas.

        Quant à la deuxième question de JGO pourquoi rester sur une ancienne version de la bibliothèque graphique ?
        Il y a des cas où la montée de version d'une bibliothèque implique, via les dépendances, des montées de version d'autres composants voire du système d'exploitation. Il faut alors valider que toutes les applications hébergées par le serveur supportent cette montée de version.
        • [^] # Re: Le merveilleux monde de l'entreprise

          Posté par . Évalué à 3.

          Pareil ici, personne ne voit l'intérêt d'acheter une version "IE7" ou "IE8" de l'appli Web qui ne tourne que sous IE6.

          Sauf que certains collègues commencent à râler car ils ont besoins d'outils Google pour certains trucs et Google est en train de laisser tomber IE6 (ils ne testent plus si ça marche avec).
          Le meilleur c'est les râleries du genre "fais chier Google" et "obligé d'installer Firefox, qu'est-ce qu'il est lourd" (c'est sûr que lancer IE6, qui n'est qu'une surcouche à l'explorateur Windows, ça demande pas grand chose sous Windows XP).

          THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: Le merveilleux monde de l'entreprise

        Posté par . Évalué à 5.

        "Passer à IE7 ou pire IE8 représente des décennies de travail."
        Sans aller jusqu'à de telles durées, je confirme que c'est malheureusement vrai, et que je vis ça tous les jours ces temps-ci : je dois tester la compatibilité d'applis Web codées sur et pour IE6 avec IE8 !
        Résultat : ce con ne sait plus gérer Ajax comme le faisait son grand-frère ! Et je ne parle pas des nombreux nouveaux bugs et régressions, je me contenterai juste de vous montrer une page Web[1] qui en répertorie quelques-uns...

        1 http://edskes.net/ie8overflowandexpandingboxbugs.htm
        (à tester avec IE et Firefox, pour bien voir les différences)

        "Par ailleurs, on a jamais de budget pour entretenir une application. Un camion, un bâtiment, une photocopieuse l'entretien est budgété, une application jamais. Ça ne doit pas vieillir ! "
        Faut croire que j'ai pas de cul ! Ils ont trouvé le pognon pour acheter ma prestation (en fait, on est 2) pour s'assurer de la compatibilité avec le futur nouveau "standard" de l'entreprise...
        Des trucs pareils, c'est à vous dégoûter d'avoir un boulot ! :-)
    • [^] # Re: Le merveilleux monde de l'entreprise

      Posté par . Évalué à 3.

      Pour éviter des emmerdes avec le client, je vais taire son nom, mais sache juste qu'il s'agit d'un grand groupe franco-<quelque chose>. Mais ce que je vais dire est très certainement valable dans d'autres grands groupes industriels.

      Le choix d'IE se "justifie" de 2 façons :
      * IE supporte les ActiveX, or certaines applis ont été codées avec cette techno, donc impossible de migrer vers un navigateur non-redmondien sans devoir les recoder (donc mettre les billets sur la table) ;
      * c'est un navigateur inclus par défaut avec Windows (autre "standard" chez le client, même pour les serveurs), ce qui signifie que pour les clients Web, il suffit de les brancher, de leur filer une IP et une page Web à interroger et c'est tout ! Rien d'autre à configurer, ni à installer, ça fonctionne direct "hors-de-la-boiboite".

      Ces 2 raisons (que je n'approuve pas, mais en tant que presta mon avis n'a aucune valeur face à la politique de tout un groupe) font que le client utilise IE (6) et restera sur IE (7/8).

      Quant à la version antédiluvienne de la bibliothèque jpgraph, c'est encore plus fourbe : actuellement, nous utilisons toujours PHP4, donc nous devons nous cantonner à des librairies qui existent encore dans cette version ! Heureusement, la migration vers PHP5 est prévue pour début 2011 (là par contre, je peux me flatter d'avoir eu une certaine influence), avec son lot de nouveautés (que ce soit au sein du langage, comme pour le rafraichissement des librairies utilisées).
    • [^] # Re: Le merveilleux monde de l'entreprise

      Posté par . Évalué à 5.

      Souvent dans les (très) grandes entreprises (un peu) vielle, c'est les stagiaires/alterants qui poussent au fure et à mesure des nouvelles techno, on (je suis alternant) font le maximum pour travailler avec toute la chaine de compilation+les techno en up to date et on test sous chrome/firefox puis on rend compatible IE.

      Pour ce dernier point ce n'est même pas une question de liberté, juste de fontionnalité (« pas envie d'avoir à utiliser IE », firefbug inexistant sous IE,etc).

      Après pourquoi les posts clients utilisent IE ? Ben ça c'est l'histoire d'une équipe de décideurs pressés, d'un marketeux et d'un powerpoint.

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

  • # autres lib

    Posté par . Évalué à 1.

    - Artichow ( http://www.artichow.org/ ) - Librairie de génération gaphique, coté serveur, en PHP.
    - une librairie coté client (en javascript) : JavaScript Diagram Builder ( http://www.lutanho.net/diagram/ )

Suivre le flux des commentaires

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