Logos webp débordent #4826

Closed
opened 1 year ago by JLuc · 8 comments
JLuc commented 1 year ago

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.
arno commented 1 year ago
Owner

Ç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).
arno commented 1 year ago
Owner

Assigné à cedric

**Assigné à cedric**
b_b commented 1 year ago
Owner

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 bien gif,jpg,png,webp, chelou ?
Statut changé à En cours

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 bien `gif,jpg,png,webp`, chelou ? **Statut changé à En cours**
JLuc commented 1 year ago
Poster

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 ?
Poster
Cf https://git.spip.net/spip/medias/issues/4815
Owner

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"
 		);
 	}
    
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" ); } ```
Poster

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.
b_b commented 3 weeks ago
Owner

On ferme.

On ferme.
b_b closed this issue 3 weeks ago
Sign in to join this conversation.
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.