filtre d'image | ombre portée sur #TITRE en image typo

Loiseau2nuit · Décembre 30, 2007, 1:19

Bonjour Messieurs,

Je me penche actuellement sur les filtres d'images embarqués de Spip.

Il se trouve que j'aime beaucoup les ombres portées et je viens de
mettre en application à l'échelle d'un #TITRE les filtres présentés
par Diala et Arno ici : http://www.paris-beyrouth.org/Une-ombre-portee

alors jusque là le rendu est plutôt sympa mais provoque plusieurs
interrogations chez moi.

Je m'explique :

en fait, j'ai fait le choix d'une police libre de texte pour ses
titres (il s'agit de la police Chancery, au format .pfb, dispo dans
The Gimp pour linux (distro ubuntu 7.10)) J'ai donc chargé la police
dans le répertoire qui va bien et j'ai appliqué le filtre
d'image_typo. Jusque là tout va bien. Ensuite j'ai appliqué la méthode
de Diala et Arno* pour y appliquer une ombre portée.

Seulement, ce à quoi je n'avais pas pensé, c'était d'une part au temps
que la page allait prendre pour calculer le fameux titre (qui, selon
les filtres en questions, se calculent quand même deux fois d'affilé
(une fois en mode image normal, une seconde en mode brûlé/flouté/
transparentée/décalée pour générer l'ombre !!!)

et d'autre part à la conformité XHTML strict de la page sortie de là.

le filtre d'Arno ne concernait à l'origine que les images attachées à
l'article mais il précise quelque part que cela peut également
s'appliquer aux images typo générées par Spip, d'où cogitations de ma
part et tripatouillages en conséquence pour obtenir le rendu final.

Le résultat est somme toute assez sympa, mais :

- ma page mets maintenant un temps fou à se générer en local (alors
qu'est ce que ca va être sur l'hébergement final en accès à
distance ???)

- j'ai 8 erreurs de validation XHTML qui sont apparues, qui semblent
provenir de la génération de code faite par les filtres.

Donc là ce que j'aimerais, ce sont quelques conseils d'utilisateurs
confirmés pour une utilisation judicieuse de ce genre de filtres.

- utilisez vous ce genre de filtres graphiques et dans quelles
proportions ?

- Niveau intégrité du code xhtml strict, qu'en pensez vous ? que
conseillez vous ? Avez vous connaissances de modifs incntournables à
effectuer quelque part dans les fichiers de Spip (core ou squelettes)
qui permettent une intégration optimale de ceux ci ?

- Avez vous un tuyau permettant daccélérer un poil le chargement des
pages ? (genre le plugin fastcache ou autre ingénuosité dont je
n'aurais eventuellement pas encore connaissance ?)

Un retour d'expérience m'aiderait vraiment beaucoup là.

En vous remerciant par avance de vos réponses.

Bonne année à tous.

Etienne.

denisb1 · Décembre 30, 2007, 3:45

=?ISO-8859-1?Q?Loiseau2nuit_(Zzz._dans_un_pass=E9_lointain...)?= <l.oiseau2nuit
<at> gmail.com> writes:

Seulement, ce à quoi je n'avais pas pensé, c'était d'une part au temps
que la page allait prendre pour calculer le fameux titre (qui, selon
les filtres en questions, se calculent quand même deux fois d'affilé
(une fois en mode image normal, une seconde en mode brûlé/flouté/
transparentée/décalée pour générer l'ombre !!!)

ha ça !
c'est sûr que le temps de travail de GD allonge coooonnnnnnsidérablement le
temps de génération de la page...

l'idéal serait de ne générer l'image qu'une fois,
de sauvegarder le résultat puis d'afficher ce résultat les fois suivantes (<img
src="...) :
un gentil petit script qui ferait ça dans l'espace privé au moment de la
rédaction du texte ;
une fonction proposée par la barre typo :
je récupère le texte sélectionné,
je lui applique les transformations typo,
je stocke le résultat dans IMG ou local/cache-vignettes/,
je remplace le texte par <imgxx|center> avec la version texte en alt=""
...
cé ki ki si kol ?

et d'autre part à la conformité XHTML strict de la page sortie de là.

mmmouiii...
un doctype XHTML pour un cms...

quand on connait les prises de tête avec la déclaration de page en
application/xhtml+xml ou en text/html,
les problèmes de rendu avec IE,
l'insertion (ou pas) des balises <![CDATA,
l'utilisation (ou pas) des & en lieu et place des &...

voir : <http://www.hixie.ch/advocacy/xhtml>
et pour ce qui touche à l'accessibilité :
<http://www.alistapart.com/articles/waiaria>

à part quelques cas bien précis, quel est l'intérêt plutôt que
du bon vieux robuste HTML 4.01 strict ?

19eb0d0ad6f2ebee089f · Décembre 30, 2007, 7:03

denisb a écrit :

Seulement, ce à quoi je n'avais pas pensé, c'était d'une part au temps
que la page allait prendre pour calculer le fameux titre (qui, selon
les filtres en questions, se calculent quand même deux fois d'affilé
(une fois en mode image normal, une seconde en mode brûlé/flouté/
transparentée/décalée pour générer l'ombre !!!)

ha ça !
c'est sûr que le temps de travail de GD allonge coooonnnnnnsidérablement le
temps de génération de la page...

l'idéal serait de ne générer l'image qu'une fois,
de sauvegarder le résultat puis d'afficher ce résultat les fois suivantes (<img
src="...) :

C'est déjà ce que fait SPIP. Il va pas s'amuser à recalculer à chaque fois l'image !

Une fois calculée, elle est stockée dans /local. Il est même possible de stocker des calculs intermédiaires (qui normalement sont automatiquement supprimés) en utilisant |image_graver

#titre|image_typo|image_masque|image_masque|image_graver|image_sepia{couleur1}
#titre|image_typo|image_masque|image_masque|image_graver|image_sepia{couleur2}

Si tu as ce code, je crois qu'en théorie (à confirmer) le premier passage calcule l'image avec tous les filtres, mais va conserver le résultat (image_graver) de #titre|image_typo|image_masque|image_masque, qui ne sera pas recalculé au deuxième passage, appliquant ainsi directement image_sepia{couleur2} sur l'image qui avait été conservée

C'est utile uniquement si un parcours de filtre est utilisé plusieurs fois sur la même image et suivi de différents filtres, sinon... ça ne fait que grossir le répertoire /local de lourds fichiers.

Dans tous les cas, une fois qu'une image a été calculée, par exemple #titre|image_typo|image_sepia, elle ne sera pas recalculée même si l'on fait var_mode=calcul ou var_mode=recalcul (sauf si le titre a changé).

Si tu as 2 fois sur ta page
#titre|image_typo|image_sepia
#titre|image_typo|image_sepia (avec le même titre), l'image ne sera calculée qu'une fois aussi (si elle n'existait déjà pas auparavant).

Pour supprimer ces images là, il faut faire : configuration>maintenance du site>supprimer le cache>supprimer le cache des images

MM.

denisb1 · Décembre 30, 2007, 8:11

Matthieu Marcillaud <marcimat <at> free.fr> writes:

C'est déjà ce que fait SPIP. Il va pas s'amuser à recalculer à chaque
fois l'image !

pour |image_typo oui, bien sûr.

Une fois calculée, elle est stockée dans /local. Il est même possible de
stocker des calculs intermédiaires (qui normalement sont automatiquement
supprimés) en utilisant |image_graver

filtre malheureusement absent de 1.9.2c

pour la question de oiseau2nuit (hibou ?) c'est le travail à partir de *cette*
image ( son #TITRE|image_typo ) qui à *chaque* fois prend un temps fou :
|image_gamma{-254} + |image_flou + |image_alpha{30}

Loiseau2nuit · Décembre 31, 2007, 1:46

Je viens de lire vos réponses.

En effet, ce sont les traitements additionnels qui prennent du temps.
La génération typo en elle même a du légèrement ralentir la page
forcément mais rien de bien méchant.

Cependant je me demande si avec Fastcache je n'ai pas moyen de gérer
ça une fois que le site sera en prod.

Je pense également faire une recherche du côté d'apache pour voir si
je ne peux pas installer un module qui me permettra de booster
légèrement mon apache2 le temps de finir mon dev.

Soit tout une série de tests à faire, à laquelle je rajoute vos
tuyaux. On verra bien ce que ca donne

Après tout, ca marche chez les autres, ya pas de raisons que ca ne
marche pas chez moi.

Merci pour vos réponses en tout cas.

On 30 déc, 21:11, denisb <den...@laposte.net> wrote:

Matthieu Marcillaud <marcimat <at> free.fr> writes:

> C'est déjà ce que fait SPIP. Il va pas s'amuser à recalculer à chaque
> fois l'image !

pour |image_typo oui, bien sûr.

> Une fois calculée, elle est stockée dans /local. Il est même possible de
> stocker des calculs intermédiaires (qui normalement sont automatiquement
> supprimés) en utilisant |image_graver

filtre malheureusement absent de 1.9.2c

pour la question de oiseau2nuit (hibou ?) c'est le travail à partir de *cette*
image ( son #TITRE|image_typo ) qui à *chaque* fois prend un temps fou :
|image_gamma{-254} + |image_flou + |image_alpha{30}

_______________________________________________
liste spip
s...@rezo.net - désabonnement : spip-...@rezo.net
Infos et archives :http://listes.rezo.net/mailman/listinfo/spip
Documentation de SPIP :http://www.spip.net/
irc://irc.freenode.net/spip
FAQ :FAQ webmestre - SPIP