Je poste ici parce qu'il me semble que c'est un bug de SPIP et non de Médiathèque.
Dans médiathèque, il y a une boucle qui affiche :
[(#LOGO_DOCUMENT{apercu,250,100})] (j'ai simplifié et testé ce code).
ça marche si les images sont redimensionnées par GD2.
Mais la page se retrouve vide (pour la partie obtenue par recuperer_fond).
Pourtant, j'avais cru comprendre que si GD2 échoue, SPIP est sensé renvoyer l'image d'origine, avec width et height du filtre en attributs html de l'img.
* RealET tapuscrivait, le 12/10/2009 01:02:
Je poste ici parce qu'il me semble que c'est un bug de SPIP et non de Médiathèque.
Dans médiathèque, il y a une boucle qui affiche :
[(#LOGO_DOCUMENT{apercu,250,100})] (j'ai simplifié et testé ce code).
ça marche si les images sont redimensionnées par GD2.
Mais la page se retrouve vide (pour la partie obtenue par recuperer_fond).Pourtant, j'avais cru comprendre que si GD2 échoue, SPIP est sensé renvoyer l'image d'origine, avec width et height du filtre en attributs html de l'img.
Preuve supplémentaire : j'ai porté la RAM d'apache de 32 à 128Mo et là, ça passe sans problème pour les grosses images.
PHP plante lamentablement lors des tentatives de creation d'image avec GD2 si la taille mémoire disponible n'est pas suffisante.
Le panneau de configuration de la lib graphique permet d'estimer une taille maxi manipulable avec GD2, mais la précision n'est pas parfaite, et il est donc possible que si cette valeur estimée est trop grande, SPIP tente parfois des manipulation qui échouent.
Peut être faudrait-il essayer une solution à base d'exception et de catch pour eviter ce vautrage complet.
Cédric