[spip-dev] Les SVG sont des images comme les autres

Une piste pourrait être profiter de l’homothétie par défaut d'un SVG. Si
dans la déclaration on ajoute an width et un height à 100% on aurait un
SVG qui s'adapterait à n'importe quel contenant.

<svg enable-background="new 0 0 417.3 339.6" viewBox="0 0 417.3 339.6"
xmlns="http://www.w3.org/2000/svg" width="100%" height="100%"
xmlns:xlink="http://www.w3.org/1999/xlink">

Jusqu'à aujourd'hui, j'utilisais un filtre perso balise_svg, qui ajoute un style="max-width:XXXpx; width: 100%;" sur la balise <svg>, plutôt que des attributs width et height.

Ça passe plutôt bien (Chrome, FF et IE).

En détail :
http://spip.pastebin.fr/57699

Attention parce que selon si l’on insère en <svg> ou en <img> ça ne se comporte pas pareil.
Là dès qu’on passe par un filtre image on a une viewBox ET un width et un height, tout en px

Le filtre |image_reduire() appliqué sur le SVG ne fait que modifier le width et le height - c’est purement artificiel mais ça alimente ensuite taille_image() et toutes les fonctions de SPIP qui ont besoin d’avoir une taille connue pour manipuler l’image ou l'afficher.

Rien n’empêche ensuite en CSS de faire tout ce qu’on veut, mais l’idée est d’avoir une image SVG qui se comporte par défaut comme une image bitmap (avec la qualité en plus)

Et la question de la rasterization était totalement indépendante, juste pour savoir si on était capable de passer un SVG en bitmap, pour pouvoir ensuite en faire autre chose - ça n’a évidemment aucun intérêt pour faire du redimensionnement ou du traitement sur l’image initiale

Oui, mon commentaire au départ se voulait une piste pour la taille (j'ai
cru comprendre qu'on cherchait à faire des images de différentes
tailles). D'ailleurs ce serait bien d'avoir un |image_reduire(%). Ou ça
existe déjà et je ne lai pas vu ?

A + et encore merci à tutti

Cerdic a écrit le 24/07/2019 à 16:25 :

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

Merci d'avoir essayé !
Dans les forums de la fonction, j'ai vu passé que certains utilisaient comme moteur de rendu Inkscape (donc, que Imagick pouvait faire appel à un moteur externe).

Mais à part monter un serveur appelable de l'extérieur pour faire ça (comme le serveur latex), je ne crois pas que ça puisse être officiellement intégré dans SPIP.

Salut,

un truc que je remarque à l'usage : le calcul des dimensions d'un SVG arrondit en pixels entiers à la valeur inférieure.

Exemple : j'ajoute une icone en logo, qui a un viewBox="0 0 17.6 13.1"
A l'arrivée, les dimensions seront de 17x13, ce qui tronque une partie de l'image à droite et en bas.

Je pense qu'il vaudrait mieux arrondir au dessus pour éviter cet effet de bord, qu'en penses tu ?

Un autre truc que je remarque à l'usage : sur un svg qui n'a pas d'attribut width dans le <svg>, image_reduire n'applique rien du tout.

Alors oui, on peut styler les svg en css, mais c'est moins propre : quand tu affiches la page sans css par exemple, le svg perd sa dimension.

Je m'attendrais à ce que image_reduire ajoute un attribut width, qu'en pensez vous ?

Autre truc : on peut enchainer balise_img et image_reduire, mais pas avec balise_svg
#CHEMIN{images/machin.png}|balise_img|image_reduire{5} OK
#CHEMIN{images/machin.svg}|balise_svg|image_reduire{5} Pas de réduction

Là aussi, je m'attendrais à ce que le fonctionnement soit similaire non ?

Un autre truc que je remarque à l'usage : sur un svg qui n'a pas d'attribut width dans le <svg>, image_reduire n'applique rien du tout.
Alors oui, on peut styler les svg en css, mais c'est moins propre : quand tu affiches la page sans css par exemple, le svg perd sa dimension.
Je m'attendrais à ce que image_reduire ajoute un attribut width, qu'en pensez vous ?

+1

(pour être sûr : tu parles bien de ce cas là : #CHEMIN{images/machin.svg}|image_reduire{5} ? )

Autre truc : on peut enchainer balise_img et image_reduire, mais pas avec balise_svg
#CHEMIN{images/machin.png}|balise_img|image_reduire{5} OK
#CHEMIN{images/machin.svg}|balise_svg|image_reduire{5} Pas de réduction

+1 aussi

J'ai un doute : on a le droit de ne mettre qu'une seule dimension avec les svg ? Dans ce cas, le navigateur garde la proportion en fonction du viewbox ?
Ou c'est forcément width + height à la fois ?

Complément d’enquête : des fois on ne sait pas à l’avance à quel type d’image on a affaire.
Si c’est un svg, on aimerait qu’il soit embeddé (donc |balise_svg), sinon on veut le tag normal (donc |balise_img).

Ça amène à faire des tests dans les squelettes de la sorte :
[(#EXTENSION}|=={svg}|oui) [(#FICHIER|balise_svg)] ]
[(#EXTENSION}|=={svg}|non) [(#FICHIER|balise_img)] ]

Dans ces cas là il serait pratique d’avoir un filtre qui fasse ça automatiquement.
Sémantiquement, je ne sais pas quel serait le nom le plus approprié, peut-être « balise_image » tout simplement : ça ne présuppose pas du tag qui va être produit ( ou ), ça dépend de l’image.

Un exemple de fonction que j’utilise de mon côté :

if (!function_exists(‘filtre_balise_img_svg’)) {
function filtre_balise_img_svg($src, $alt=’’, $class=’’) {
include_spip(‘inc/filtres’);
$balise = ‘’;
// Récupérer le chemin si c’est déjà un tag
if (substr(trim($src), 0, 4) === ‘<img’) {
$src = extraire_attribut($src, ‘src’);
}
// Retrouver l’extension
$src = supprimer_timestamp($src);
$extension = pathinfo($src, PATHINFO_EXTENSION);
// Si c’est un svg, on embed
if ($extension === ‘svg’) {
$balise = filtrer(‘balise_svg’, $src, $alt, $class);
// Sinon, balise_img si pas déjà le cas
} else {
$balise = filtrer(‘balise_img’, $src, $alt, $class);
}
return $balise;
}
}

Hello,

oui alors :

- les filtres images sont conçus pour s’appliquer exclusivement sur les balises <img>. Peut-être que dans le futur on pourra étendre aux balises <svg> mais pour le coup c’est un chantier plus ambitieux qui a pas mal d’impacts à tous les étages, à creuser donc

- c’est pas parce qu’une image est au format svg qu’on veut forcément l’embedder dans une balise <svg> dans le html. C’est sans doute vrai pour des icones ou petits fichiers légers, mais si on a affaire à un SVG contribué par l’utilisateur qui fait 100ko+ c’est pas super malin : ça alourdit le html, et on se prive du cache navigateur sur les ressources images.

Je ne pense donc pas que prévoir un filtre automatique qui switch du img au svg selon l’extension soit pertinent.
Ça peut-être utile oui, mais ça dépendra fortement du contexte, des choix d’implémentation, et des arbitrages rapidité.

Il me semble qu’en l’état le plus malin serait un filtre ajouté en fin de chaine sur les traitements images, genre

[(#LOGO_ARTICLE|image_reduire{…}|image_rotation{…}|image_flou{…}|embed_svg_si_malin)]

filtre embed_svg_si_malin qui itère sur les balises <img> du contenu (car on peut appliquer la même chose sur #TEXTE, récupère l’attribut src, regarde si c’est un SVG, si il remplit les conditions qu’on veut imposer (poids maxi en octets par exemple), et le cas échéant remplace la balise img par une balise svg.

Cela a le mérite d’être applicable à toute image contribuée y compris via un modèle fourni par un plugin ou tout autre chose de ce cas.

A noter que ça pourrait être l’objet d’un traitement automatique via le pipeline appelé en fin de traitement sur les images, et donc éventuellement packagé dans un plugin qui fait ça et permet de personnaliser le critère de poids (et d’autres critères éventuels?)

En ce qui concerne les attributs height/width du SVG, ils sont normalement automatiquement ajoutés au SVG qui n’en a pas, en récupérant les infos de la viewbox.
Donc si il y a des cas qui ne marchent pas, il serait bien d’avoir le code pour reproduire et corriger, en effet !

Vraiment super travail, merci et bravo !!

françois

Hello tous, Meilleurs vœux.

Grattez dans vos souvenirs, art-logic est de retour... :slight_smile:

Juste un mot pour vous inviter en Haute Savoie à l'occasion de la diffusion d’un film documentaire : La bataille du Libre, du réalisateur Philippe Borrel

Bande annonce: https://vimeo.com/309626671

Réservations:

https://s.cinemaspathegaumont.com/#/V3191S4339/booking?pos=c2VhdGluZw%3D%3D

Au plaisir d'y retrouver des spipeurs.

Tous mes vœux libres.

oui carrement. c’est génial. merci ! il faudra que l’on le documente aussi.

Le 18/07/2019 à 11:35, Cerdic a écrit :

On est en 2019, la version trunk de SPIP supporte maintenant totalement les SVG comme des images.

Yep, giga merci !

Peetdu

Le jeu. 18 juil. 2019 11:36, Cerdic a écrit :

Hello,

On est en 2019, la version trunk de SPIP supporte maintenant totalement
les SVG comme des images.
Can I use... Support tables for HTML5, CSS3, etc

Cela veut dire :

[...]

Juste wawou... Beau boulot les artistes !

Le 24/07/2019 à 23:52, nicod_ a écrit :

Le 24/07/2019 à 16:39, Luis Speciale a écrit :

Une piste pourrait être profiter de l’homothétie par défaut d'un SVG. Si
dans la déclaration on ajoute an width et un height à 100% on aurait un
SVG qui s'adapterait à n'importe quel contenant.

<svg enable-background="new 0 0 417.3 339.6" viewBox="0 0 417.3 339.6"
xmlns="http://www.w3.org/2000/svg&quot; width="100%" height="100%"
xmlns:xlink="http://www.w3.org/1999/xlink&quot;&gt;

Jusqu'à aujourd'hui, j'utilisais un filtre perso balise_svg, qui ajoute
un style="max-width:XXXpx; width: 100%;" sur la balise <svg>, plutôt que
des attributs width et height.

Ça passe plutôt bien (Chrome, FF et IE).

En détail :
http://spip.pastebin.fr/57699

Oui. Mais ce n'est pas "plûtot que", c'est "en plus de". Et tu limites
au passage. width="100%" height="100%" c'est plus simple.

2 messages ont été scindés en un nouveau sujet : forcer image_aplatir{jpg} sur un svg ?