Les logos débordent de leur colonne sur l'espace du texte principal lorsqu'ils sont trop grands. Constaté sur contrib, allwaysdata mutu, OVH mutu et gandi simplehosting. Sur ces 2 derniers au moints, le "WebP Support" est "enabled".
Page exemple où ça se voit : https://contrib.spip.net/ecrire/?exec=article&id_article=5288
Le pb semble être que c'est le fichier original du logo qui est affiché, redimensionné par le html (width=, comme les logos dans les listes d'ailleurs) à une largeur de 320px calculée et imposée par SPIP : img src="../IMG/logo/framboise.resized.webp?1623097946" style="max-width: 320px; max-height: 320px" alt="logo_on"
Mais la colonne ne fait que 286px de large d'après l'inspecteur.
Ça se joue dans prive/formulaires.inc-apercu-logo.html dont le dernier log est "arrêter les logos riquiqui" et passe la largeur de 300 à 320px : d5ae227fd4 . Mais 320 ça semble trop ou alors faut aussi élargir la colonne.
Les logos débordent de leur colonne sur l'espace du texte principal lorsqu'ils sont trop grands. Constaté sur contrib, allwaysdata mutu, OVH mutu et gandi simplehosting. Sur ces 2 derniers au moints, le "WebP Support" est "enabled".
Page exemple où ça se voit : https://contrib.spip.net/ecrire/?exec=article&id_article=5288
Le pb semble être que c'est le fichier original du logo qui est affiché, redimensionné par le html (width=, comme les logos dans les listes d'ailleurs) à une largeur de 320px calculée et imposée par SPIP : img src="../IMG/logo/framboise.resized.webp?1623097946" style="max-width: 320px; max-height: 320px" alt="logo_on"
Mais la colonne ne fait que 286px de large d'après l'inspecteur.
Ça se joue dans [prive/formulaires.inc-apercu-logo.html](https://git.spip.net/spip/spip/src/branch/master/prive/formulaires/inc-apercu-logo.html) dont le dernier log est "arrêter les logos riquiqui" et passe la largeur de 300 à 320px : https://git.spip.net/spip/spip/commit/d5ae227fd47a94d1148f7d34b6f616147bf78816 . Mais 320 ça semble trop ou alors faut aussi élargir la colonne.
Ça n'a rien à voir avec la modification citée (parce que 300 pixels, ça dépassera aussi :-)).
Le souci c'est que le image_reduire ne s'applique pas sur une image WebP.
La raison étant que WebP n'est pas dans les formats déjà détectés et stockés dans:
$GLOBALS['meta']['gd_formats']
, et donc on échoue sur “_image_extensions_acceptees_en_sortie()” qui lui-même passe par “_image_extensions_acceptees_en_entree()” (c'est lui qui refuse WebP).
Il faudrait donc supprimer et recalculer la valeur du méta lors de l'activation de WebP (je ne sais pas faire).
Ça n'a rien à voir avec la modification citée (parce que 300 pixels, ça dépassera aussi :-)).
Le souci c'est que le `image_reduire` ne s'applique pas sur une image WebP.
La raison étant que WebP n'est pas dans les formats *déjà détectés* et stockés dans: <pre>$GLOBALS['meta']['gd_formats']</pre>, et donc on échoue sur “_image_extensions_acceptees_en_sortie()” qui lui-même passe par “_image_extensions_acceptees_en_entree()” (c'est lui qui refuse WebP).
Il faudrait donc supprimer et recalculer la valeur du méta lors de l'activation de WebP (je ne sais pas faire).
Modifier la valeur de l'option "Autoriser la génération de vignette" a un impact sur ce problème. Quand on autorise la génération des vignettes, il semble que la vignette ne déborde pas.
Attention : Il y a un hystérésis ensuite puisqu'une fois la vignette créée elle est utilisée même si on retire l'autorisation de génération. Ça rend le test plus délicat.
Le problème serait il dû au code HTML généré lorsque image_reduire n'est pas appelé ?
Au passage je vois que la fonction action_tester_dist à la fois fait un test de transformation d'image ET écrit la meta gd_format. N'est ce pas une confusion des genres ?
Modifier la valeur de l'option "Autoriser la génération de vignette" a un impact sur ce problème. Quand on autorise la génération des vignettes, il semble que la vignette ne déborde pas.
Attention : Il y a un hystérésis ensuite puisqu'une fois la vignette créée elle est utilisée même si on retire l'autorisation de génération. Ça rend le test plus délicat.
Le problème serait il dû au code HTML généré lorsque image_reduire n'est pas appelé ?
Au passage je vois que la fonction action_tester_dist à la fois fait un test de transformation d'image ET écrit la meta gd_format. N'est ce pas une confusion des genres ?
En fait quand on sait pas réduire une image parce que format pas supporté comme ici, le fallback c'est de garder l'image d'origine et de la réduire juste visuellement via un max-height en dur sur la balise img
du coup le max-width en inline prend la main sur celui de la css qui était un max-width:100%
On devrait donc plutôt insérer un max-width: min(100%,320px); pour être plus robuste.
Mais en regardant le code, on voit que ce max-width est un fallback du fallback, c'est à dire si on connait pas du tout les dimensions du fichier parce qu'il n'y a ni width/height sur la balise img.
On aurait pas eu le bug si au départ on avait appliqué un filtre |balise_img avant d'appliquer |image_reduire.
Mais on peut facilement améliorer en appelant taille_image() qui sera plus robuste.
Je propose donc un double patch :
diff --git a/ecrire/inc/filtres_images_lib_mini.php b/ecrire/inc/filtres_images_lib_mini.php
index 459c45f4a..171e4af2b 100644
--- a/ecrire/inc/filtres_images_lib_mini.php
+++ b/ecrire/inc/filtres_images_lib_mini.php
@@ -1780,12 +1780,10 @@ function process_image_reduire($fonction, $img, $taille, $taille_y, $force, $pro
}
if (!is_array($image) or !$image['largeur'] or !$image['hauteur']) {
- spip_log("image_reduire_src:pas de version locale de $img");
+ spip_log("image_reduire_src:pas de version locale de $img ou extension non prise en charge");
// on peut resizer en mode html si on dispose des elements
- if (
- $srcw = extraire_attribut($img, 'width')
- and $srch = extraire_attribut($img, 'height')
- ) {
+ [$srcw, $srch] = taille_image($img);
+ if ($srcw and $srch) {
[$w, $h] = _image_ratio($srcw, $srch, $taille, $taille_y);
return _image_tag_changer_taille($img, $w, $h);
@@ -1795,7 +1793,7 @@ function process_image_reduire($fonction, $img, $taille, $taille_y, $force, $pro
return inserer_attribut(
$img,
'style',
- "max-width: ${taille}px; max-height: ${taille_y}px"
+ "max-width: ${taille}px;max-width: min(100%,${taille}px); max-height: ${taille_y}px"
);
}
En fait quand on sait pas réduire une image parce que format pas supporté comme ici, le fallback c'est de garder l'image d'origine et de la réduire juste visuellement via un max-height en dur sur la balise img
Ici ça donne
```
<img src="../IMG/logo/framboise-2.webp?1623096792" style="max-width: 320px; max-height: 320px" alt="logo_on">
```
du coup le `max-width` en inline prend la main sur celui de la css qui était un `max-width:100%`
On devrait donc plutôt insérer un
`max-width: min(100%,320px);` pour être plus robuste.
Mais en regardant le code, on voit que ce max-width est un fallback du fallback, c'est à dire si on connait pas du tout les dimensions du fichier parce qu'il n'y a ni width/height sur la balise img.
On aurait pas eu le bug si au départ on avait appliqué un filtre `|balise_img` avant d'appliquer `|image_reduire`.
Mais on peut facilement améliorer en appelant `taille_image()` qui sera plus robuste.
Je propose donc un double patch :
```
diff --git a/ecrire/inc/filtres_images_lib_mini.php b/ecrire/inc/filtres_images_lib_mini.php
index 459c45f4a..171e4af2b 100644
--- a/ecrire/inc/filtres_images_lib_mini.php
+++ b/ecrire/inc/filtres_images_lib_mini.php
@@ -1780,12 +1780,10 @@ function process_image_reduire($fonction, $img, $taille, $taille_y, $force, $pro
}
if (!is_array($image) or !$image['largeur'] or !$image['hauteur']) {
- spip_log("image_reduire_src:pas de version locale de $img");
+ spip_log("image_reduire_src:pas de version locale de $img ou extension non prise en charge");
// on peut resizer en mode html si on dispose des elements
- if (
- $srcw = extraire_attribut($img, 'width')
- and $srch = extraire_attribut($img, 'height')
- ) {
+ [$srcw, $srch] = taille_image($img);
+ if ($srcw and $srch) {
[$w, $h] = _image_ratio($srcw, $srch, $taille, $taille_y);
return _image_tag_changer_taille($img, $w, $h);
@@ -1795,7 +1793,7 @@ function process_image_reduire($fonction, $img, $taille, $taille_y, $force, $pro
return inserer_attribut(
$img,
'style',
- "max-width: ${taille}px; max-height: ${taille_y}px"
+ "max-width: ${taille}px;max-width: min(100%,${taille}px); max-height: ${taille_y}px"
);
}
```
Testé et ça marche : le rendu du logo dans sa colonne est parfait.
Au passage bravo SPIP et Cerdic pour cette épatante simulation des traitements d'images lorsque la g-librairie ne les prend pas en charge.
Testé et ça marche : le rendu du logo dans sa colonne est parfait.
Au passage bravo SPIP et Cerdic pour cette épatante simulation des traitements d'images lorsque la g-librairie ne les prend pas en charge.
Les logos débordent de leur colonne sur l'espace du texte principal lorsqu'ils sont trop grands. Constaté sur contrib, allwaysdata mutu, OVH mutu et gandi simplehosting. Sur ces 2 derniers au moints, le "WebP Support" est "enabled".
Page exemple où ça se voit : https://contrib.spip.net/ecrire/?exec=article&id_article=5288
Le pb semble être que c'est le fichier original du logo qui est affiché, redimensionné par le html (width=, comme les logos dans les listes d'ailleurs) à une largeur de 320px calculée et imposée par SPIP : img src="../IMG/logo/framboise.resized.webp?1623097946" style="max-width: 320px; max-height: 320px" alt="logo_on"
Mais la colonne ne fait que 286px de large d'après l'inspecteur.
Ça se joue dans prive/formulaires.inc-apercu-logo.html dont le dernier log est "arrêter les logos riquiqui" et passe la largeur de 300 à 320px :
d5ae227fd4. Mais 320 ça semble trop ou alors faut aussi élargir la colonne.Ça n'a rien à voir avec la modification citée (parce que 300 pixels, ça dépassera aussi :-)).
Le souci c'est que le
image_reduirene s'applique pas sur une image WebP.La raison étant que WebP n'est pas dans les formats déjà détectés et stockés dans:
, et donc on échoue sur “_image_extensions_acceptees_en_sortie()” qui lui-même passe par “_image_extensions_acceptees_en_entree()” (c'est lui qui refuse WebP).Il faudrait donc supprimer et recalculer la valeur du méta lors de l'activation de WebP (je ne sais pas faire).
Assigné à cedric
Comme je le disais dans https://core.spip.net/issues/4756#note-22 "ça marche chez moi ©", et si je dump
$GLOBALS['meta']['gd_formats']j'ai biengif,jpg,png,webp, chelou ?Statut changé à En cours
Modifier la valeur de l'option "Autoriser la génération de vignette" a un impact sur ce problème. Quand on autorise la génération des vignettes, il semble que la vignette ne déborde pas.
Attention : Il y a un hystérésis ensuite puisqu'une fois la vignette créée elle est utilisée même si on retire l'autorisation de génération. Ça rend le test plus délicat.
Le problème serait il dû au code HTML généré lorsque image_reduire n'est pas appelé ?
Au passage je vois que la fonction action_tester_dist à la fois fait un test de transformation d'image ET écrit la meta gd_format. N'est ce pas une confusion des genres ?
Cf spip/medias#4815
En fait quand on sait pas réduire une image parce que format pas supporté comme ici, le fallback c'est de garder l'image d'origine et de la réduire juste visuellement via un max-height en dur sur la balise img
Ici ça donne
du coup le
max-widthen inline prend la main sur celui de la css qui était unmax-width:100%On devrait donc plutôt insérer un
max-width: min(100%,320px);pour être plus robuste.Mais en regardant le code, on voit que ce max-width est un fallback du fallback, c'est à dire si on connait pas du tout les dimensions du fichier parce qu'il n'y a ni width/height sur la balise img.
On aurait pas eu le bug si au départ on avait appliqué un filtre
|balise_imgavant d'appliquer|image_reduire.Mais on peut facilement améliorer en appelant
taille_image()qui sera plus robuste.Je propose donc un double patch :
Testé et ça marche : le rendu du logo dans sa colonne est parfait.
Au passage bravo SPIP et Cerdic pour cette épatante simulation des traitements d'images lorsque la g-librairie ne les prend pas en charge.
On ferme.