On est en 2019, la version trunk de SPIP supporte maintenant totalement les SVG comme des images.
Cela veut dire :
• qu’on peut les uploader comme des images dans les documents joints
• qu’on peut les uploader comme logo d’objet
• que les aperçus de SVG s’affichent bien partout dans l’espace privé
• que les filtres |image_xxx utilisés partout dans les squelettes pourront s’appliquer dessus sans rien casser
• soit en appliquant la même transformation que pour un bitmap si le filtre |image_xx supporte expressément les SVG
• soit en ne faisant rien si le filtre n’a pas été modifié pour supporter les SVG
En l’état les filtres suivants supportent désormais également les images au format SVG :
image_reduire
image_passe_partout
image_recadre
image_aplatir (conserve un svg mais applique le background)
image_format (conserve un svg mais applique le background)
image_alpha
image_flip_vertical
image_flip_horizontal
image_flou
image_nb
image_sepia
image_gamma
image_rotation
couleur_extraire (extrait une moyenne des couleurs referencees dans le SVG, sans notion de leur importance visuelle)
avec la réserve que pour certains filtres (flou, sepia, nb) il faut que le navigateur supporte bien les CSS filters dans les SVG :seul FF le supporte actuellement - dans les navigateurs qui ne le supportent pas l’effet est juste ignoré.
(Il semble être possible d’utiliser des features filter avancées des SVG qui sont mieux supportées mais je n’ai pas creusé dans cette voie)
Dans le core, les filtres qui ne supportent pas le SVG (et sont donc sans effet) sont :
image_masque (on devrait pouvoir porter une partie des fonctionnalités mais c’est plus compliqué)
image_renforcement (sans objet?)
image_fond_transparent (sans objet)
image_imagick (sans objet)
image_recadre_mini (sans objet)
Le support des filtres images devrait permettre d’utiliser des images SVG directement, sans aucune modification des squelettes ni de code, sauf peut être dans certain cas de filtres images perso un peu velus qui modifient notamment les dimensions de l’image
(dans ce cas il faudrait au moins une implémentation mini pour modifier les dimensions du SVG à l’identique)
J'ai juste des questions
1. Le plugin actuel "logo-svg" utilise une librarie pour sécuriser le svg. Est-ce qu'une telle librairie est appliqué.
2. Quid de la possibilité sur un image_reduire appliqué à du svg de préciser des tailles relatives (genre "1em") ?
Pour la sanitization du SVG il y avait déjà quelque chose dans le core, mais il est bien possible en effet que dans le cas des logos on ne repasse pas dedans, à vérifier/corriger
Pour la taille des |image_reduire en em c’est non et ça n’a aucun intérêt.
Il faut comprendre que le SVG est vectoriel, donc la notion de taille d’affichage n’est qu’un artifice. Ici ça consiste à mettre le bon width et height sur la balise svg et sur la baise IMG. Ça va donc juste conditionner l’affichage par défaut dans le navigateur, en l’absence de style.
Mais tu passer un coup de CSS par dessus ensuite pour faire ce que tu veux.
Par contre |image_reduire est supposé marcher de la même façon sur une image en pixels et sur une image svg, il ne peut donc prendre que des px comme unité
• la sanitization n’était pas appelée pour les logos -> corrigé
• la sanitization n’était pas appliquée pour les admins -> j’ai enlevé ça, elle s’applique quel que soit l’utilisateur qui upload
• la sanitization utilisait safehtml et foirait les images SVG (au moins celles que j’avais sous la main pour tester) -> j’ai mis la lib svg-sanitizer utilisée par le plugin qui semble bien meilleure
sur une fresh install de ce matin (3.3.0-dev SVN [24342]), j’ai des messages d’erreurs (14 fois le même) à la 1ère connexion à l’espace privé après installation et l’installation des 1ers plugins :
Hello,
Il y a deux problèmes avec la rasterization des SVG
* image_aplatir{jpg} est utilisé potentiellement assez systématiquement pour optimiser la taille des images, a minima après chaque série de filtre de transformation qui opèrent en PNG, voire un peu partout (en tout cas je fais ça assez systématiquement), avec le postulat implicite que l’image source est toujours un bitmap.
Donc si on faisait opérer |image_aplatir sur les SVG on perdrait presque systématiquement tout leur intérêt.
Peut-être il faudrait un filtre |image_rasterize pour aplatir les SVG, ou un |image_aplatir_si_bitmap qui opère que sur les bitmaps ?
En tout cas donc pour le moment il m’a semblé contre-productif de convertir les SVG en bitmaps
* très matériellement je ne sais pas si on va trouver une lib qui fait ça sérieusement et proprement (mais je n’ai pas cherché)
Il s’agit encore une fois de refaire en PHP un moteur de rendu SVG->image, job que les navigateurs ont du mal à faire bien et complètement. Je crains que ce ne soit qu’une source de bug et d’insatisfaction, car il y aura toujours des SVG qui seront mal rendus.
Peut-être il faut considérer que c’est quand même un besoin un peu à part et qu’on peut traiter en plugin le cas échéant. Et si une lib semble robuste, fiable maintenue etc on pourra toujours la mettre dans le core
(l’adresse spip-core ne semble plus exister, c’était là qu’on envoyait les mails d’annonce de nouvelle feature pour les retrouver au moment de la release et pouvoir faire facilement un article avec toutes les nouveautés…)
Peut-être qu’à partir du moment où on va manipuler fréquement des bitmaps et des svg, le besoin va se faire sentir.
Il y a déjà le cas borderline du couleur_extraire, où j’ai feinté pour faire une moyenne des couleurs référencées dans le svg, mais c’est très approximatif car cela ne prends pas en compte l’importance de chaque couleur sur le rendu global. Idéalement il aurait fallu rasterizer puis extraire la couleur du bitmap.
On verra à l’usage, et si on trouve une lib un peu smart qui fait ça (dans le cas de couleur_extraire par exemple, on a pas forcément besoin d’un rendu 100%, même si la lib ignore certaines instructions qu’elle ne sait pas rendre ce n’est pas très grave)
Mais en tout cas oui, ça me paraissait le plus judicieux de garder les SVG dans ce format via |image_aplatir (mais en appliquant juste le background de la couleur demandée pour supprimer la transparence éventuelle)
On verra à l’usage, et si on trouve une lib un peu smart qui fait ça (dans le cas de couleur_extraire par exemple, on a pas forcément besoin d’un rendu 100%, même si la lib ignore certaines instructions qu’elle ne sait pas rendre ce n’est pas très grave)
Si le serveur a Imagick, ça a l'air d'être une fonction native de la lib
J’ai fait un test rapide sur le premier SVG venu trouvé dans un moteur de recherche, qui est tout petit mais avec des transform et des gradients, et franchement le résultat est totalement inexploitable (ie tellement loin de ressemble à l’image SVG que même pour couleur_extraire je suis pas sur que ce soit intéressant)
Je ne pense même pas que ça vaille la peine de commit le debut de filtre que j’ai fait avec ça mais c’est là si vous voulez tester http://spip.pastebin.fr/57695
