Bonjour,
Après en avoir causé hier sur IRC, je vous soumets ce bug :
j'ai un bug réccurent sur les images typographiques qui n''est pas arrangé par
la mise à jour en 2.1.
J'obtiens, bien que l'image soit calculée cette liste d'erreurs:
Il me faut au moins trois recalculs pour que l'erreur disparaisse...
Auriez-vous une idée, rencontré ce bug etc... ?
Merci d'avance
LPG
Bonjour,
Après en avoir causé hier sur IRC, je vous soumets ce bug :
j’ai un bug réccurent sur les images typographiques qui n’'est pas arrangé par
la mise à jour en 2.1.J’obtiens, bien que l’image soit calculée cette liste d’erreurs:
Et cela se produit sur quel code?
Il me faut au moins trois recalculs pour que l’erreur disparaisse…
Auriez-vous une idée, rencontré ce bug etc… ?
Nope … mise à part un sous dimensionnement serveur par rapport à ce que tu souhaites faire…
Mais encore faudrait il le savoir…
Merci d’avance
LPG
kent1 (pas spécialiste du tout de la chose)
Yo Kent1,
Et cela se produit sur quel code?
Dans les boucles articles (toutes) lorsque j'utilise ça :
[(#TITRE|image_typo{police=Stag-Bold.ttf,taille=20,couleur=cc6600,largeur=550})]
La police étant dans un repertoire protégé par un .htaccess (j'ai essayé sans,
ça ne change rien): la
transformation du titre texte en titre image se fait bien au deuxième
vidage de cache.
Il me faut au moins trois recalculs pour que l'erreur disparaisse...
Auriez-vous une idée, rencontré ce bug etc... ?Nope ... mise à part un sous dimensionnement serveur par
rapport à ce que tu souhaites faire...
Mais encore faudrait il le savoir...
Le serveur peut traiter des images jusqu'à 8Mega...
LPG
J'aurais tendance à pense que le problème vient de la police.
Tu as essayé avec une autre pour voir si le problème est identique ?
Cédric
J'aurais tendance à pense que le problème vient de la police.
Tu as essayé avec une autre pour voir si le problème est identique ?Cédric
Cedric, Kent1,
Sorry de ma lente réponse, je me suis écroulée hier.
Ça le fait partout où j'utilise l'image typo donc sur tous les titres
(articles, rubriques).
J'ai essayé avec la police par défaut et j'ai du mal à dire si ça va mieux,
car je n'arrive pas (même en
vidant le contenu des sous rep de local à la main) à
vraiment vider le cache image...
Cedric, tu penses que c'est la police c'est à dire : le repertoire
avec htaccess? Ou autre chose ?
Merci d'avance,
LPeg
J'aurais tendance à pense que le problème vient de la police.
Tu as essayé avec une autre pour voir si le problème est identique ?Cédric
Cedric, Kent1,
Sorry de ma lente réponse, je me suis écroulée hier.
Ça le fait partout où j'utilise l'image typo donc sur tous les titres
(articles, rubriques).J'ai essayé avec la police par défaut et j'ai du mal à dire si ça va mieux,
car je n'arrive pas (même en
vidant le contenu des sous rep de local à la main) à
vraiment vider le cache image...
Ben c'est bizarre ton histoire car si tu changes de police dans |image_typo{...} c'est une image différente qui est générée, et le cache ne change donc rien.
Cedric, tu penses que c'est la police c'est à dire : le repertoire
avec htaccess? Ou autre chose ?
Non je parles du fichier de la police, le ttf. Parfois il y a des soucis avec certaines qui ne sont, je suppose, pas très bien formatée.
Le htaccess ne gêne en rien lui
Cédric
j'ai exactement les mêmes symptômes sous SPIP 2.0.10 (avec l'erreur sur imagecreatetruecolor() le plus fréquemment et parfois les autres) lors de l'usage de |image_typo. Le serveur est un Linux où apache dispose de 128 Mo de RAM et qui est (très) loin d'être surchargé.
A priori il doit y avoir quelque chose avec le serveur et/ou les droits d'écriture plutôt que la police puisque sur un clône de ce site sur ma machine de développement (sous Windows, 128 Mo de RAM pour apache aussi) je n'ai *jamais* l'erreur.
Possible aussi que ça vienne de la librairie gd et de son extension
utilisée pour lire les polices ttf
Cédric
Essayer avec un texte «pur ASCII», sans accents, sans apostrophe. Genre «ABCabc». Est-ce que là ça passe?
Il est fréquent que les polices TTF un peu anciennes utilisent un vieux charset, qui plus est un des charsets pur Windows. Si ça se trouve, les lettres accentuées de vos titres, du coup, vont taper dans des cases de la casse de caractères qui font déconner la police. Perso ça ne me provoque pas d'erreur, juste l'affichage des mauvaises lettres, mais ça se teste. Ça pourrait expliquer pour ça fonctionne sous Windows et pas sur un serveur Linux (peut-être que la version de GD pour Windows est capable de choses typiquement Windows que ne permet pas la version Linux liées à l'ouverture des polices).
Sinon, ouvrir la police avec un éditeur de police de caractère (perso, FontLab, mais c'est loin d'être un logiciel libre; essayer FontForge, qui est un logiciel libre) et refabriquer un fichier TTF («Generate Font») à partir de ce logiciel. Perso, je fais ça pour être certain que ma police d'origine est bien réencodée dans le bon charset. Mais peut-être que ça pourrait vous «nettoyer» une police qui aurait un problème de format.
http://fontforge.sourceforge.net/
Arnaud
Essayer avec un texte «pur ASCII», sans accents, sans apostrophe.
Genre «ABCabc». Est-ce que là ça passe?
soupçonnant un truc dans le style j'ai même essayé en passant un filtre
pour supprimer les caractères accentués => pas mieux!
Il est fréquent que les polices TTF un peu anciennes utilisent un
vieux charset, qui plus est un des charsets pur Windows. Si ça se
trouve, les lettres accentuées de vos titres, du coup, vont taper
dans des cases de la casse de caractères qui font déconner la police.
Perso ça ne me provoque pas d'erreur, juste l'affichage des mauvaises
lettres, mais ça se teste. Ça pourrait expliquer pour ça fonctionne
sous Windows et pas sur un serveur Linux (peut-être que la version de
GD pour Windows est capable de choses typiquement Windows que ne
permet pas la version Linux liées à l'ouverture des polices).
ben oui mais non: là j'ai l'erreur avec la Dustismo livrée avec la dist de SPIP...
Pour être exhaustif dans la description du problème:
- les erreurs sont présentes quelle que soit la
bibliothèque php sélectionnée dans la
configuration "Méthode de fabrication des vignettes" du SPIP
(testé avec GD1, GD2, convert et netpbm)
- j'ai aussi:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 134218696 bytes) in /home1/virtuals/galactron.org/html/ecrire/inc/filtres_images.php on line 2475
de façon récurrente (en alternance avec les erreurs moins "fatales" signalées par lpg)
Cette ligne 2475 correspond à l'appel de la fonction
imageCreateTrueColor() avec les paramètres de largeur et hauteur
de l'image contenant le texte à afficher:
$im = imageCreateTrueColor($largeur_reelle-$espace+(2*$padding),
$hauteur+5+(2*$padding));
En traçant ce qui se passe au moment de l'appel de cette
fonction, l'origine du problème semble se situer au niveau de la fonction php imageftbbox() utilisée pour calculer $espace (= la taille du rectangle encadrant le texte):
=> serveur Linux au premier calcul de la page:
$espace: -33554432
=> serveur Linux au 2ème ou 3ème recalcul:
$espace: 11
=> serveur Windows dès le premier calcul:
$espace: 11
Cette fonction dépendant elle-même de freetype2 cela pourrait expliquer les différences constatées entre les serveurs (?)
Ce que je comprend très mal c'est pourquoi la fonction foire au premier calcul de la page mais pas par la suite!
Ceci étant, sans me poser plus de questions métaphysico-phpéiennes, j'ai profité de cette anomalie pour tester un très malhonnête patch (cf pièce attachée) qui semble contourner le problème chez moi (SPIP 2.0.10)...
C'est crade, certes, mais au moins je n'ai plus l'erreur à chaque recalcul d'une page avec un |image_typo dedans: si des *vrais* devs ont une soluce plus propre je suis bien sûr preneur...
à bientôt
filtres_images.php.patch (1.81 KB)