http://zone.spip.org

  • Nouvelle fonction rigolote dans mon #plugin #SPIP image_responsive 7.0 :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Il y a désormais un filtre image_responsive_svg (qui fonctionne en gros comme image_responsive, avec pour l’instant seulement les variables $img, $tailles, $lazy et $vertical.

    Le but est de résoudre mon souci avec l’utilisation des images JPG à l’intérieur d’un <svg> : là les images sont appelées avec :

    <image xlink:href>

    au lieu de l’habituel <img src> du HTML.

    Importantes différences cependant avec le filtre image_responsive :
    – on ne peut pas définir de mediaqueries pour chaque dimension, parce que je n’ai pas (encore ?) trouvé de méthode pour afficher directement les bons fichiers via des CSS (et encore moins, évidemment, une balaise <picture>) ; c’est le point qui m’embête le plus ;
    – on ne peut pas définir des redimensionnement spécifiques pour chaque taille d’image, parce que j’ai l’impression qu’il est difficile changer les proportions d’un SVG.

    (Bon, et pis franchement franchement : je crois que je vais la seule personne sur la planète à utiliser cette fonction, alors bon…)

  • Salut #SPIP,

    Je suppose que c’est une question classique : j’ai besoin de traiter (dans un plugin) le code du texte formaté après y avoir inséré les modèles.

    Or, le pipeline post_propre est appelé par traiter_raccourcis ; et traiter_raccourcis est appelé dans la fonction propre avant qu’on remette en place le code issu des modèles (via echappe_retour_modeles). Donc le pipeline post_propre est déclenché avant qu’on ait remis les <modeles> dans le texte. Je n’y ai donc pas accès par là.

    Bref : est-ce qu’il y a un pipeline qui permet d’attaquer le texte formaté avec le résultat des modèles qu’il contient ?

  • Chouette nouveauté dans mon #plugin #SPIP centre_image :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/centre_image

    J’ai ajouté la détection du « centre » de l’image via le script de détection de visage de Maurice Svay :
    https://github.com/mauricesvay/php-facedetection

    Pour l’instant, c’est à utiliser comme une fonction séparée : centre_image_visage. Par exemple :

    left: [(#FICHIER|centre_image_visage|table_valeur{x}|mult{100})]%;
    top: [(#FICHIER|centre_image_visage|table_valeur{y}|mult{100})]%;

    Je pense que je vais l’intégrer dans la fonction centre_image de base sous forme d’option activable par une constante, parce que le résultat est extrêmement plus réussi que la fonction de base lorsqu’il y a un visage dans l’image. Mais alors… c’est beaucoup plus lourd.

    Pour comparer, voici une collection de photos : le petit carré blanc marque le centre du visage (attention : la taille est indifférente, je ne récupère pas la « taille » du visage), et le petit carré rouge marque le « centre d’intérêt » détecté avec la fonction usuelle du plugin. La différence de taux de réussite est assez impressionnante (quand il détecte bien le visage, c’est ultra-précis) :

    • C’est vraiment plus lourd. À quel point, c’est difficile à évaluer comme ça, mais de mes essais je dirais au moins entre 5 et 10 fois plus lourd. Sur mon Mac en local, c’est quasiment pas possible de faire le calcul sur plusieurs images en même temps ; sur le serveur dédié, ça va…

      Bon, d’un autre côté une fois que c’est calculé pour une image, il y a un cache. Et comme ça lance automatiquement le calcul pour les images dans l’espace privé quand tu les installes, c’est assez supportable.

    • Comment se passe le traitement des images déjà présentes ? Une tâche automatisée ? Que se passe-t-il pour les images pour lesquelles le centre a été déterminé manuellement (différence de traitement) ?
      Merci en tout cas !

    • – Quand on passe d’une méthode à l’autre, le « centre_image » est stocké dans deux caches différents, du coup pas de perturbation entre les deux.

      – En revanche, si on a forcé manuellement le point d’intérêt, on conserve ce point manuel même avec le basculement d’une méthode à l’autre.

  • Nouveauté dans mon #plugin #SPIP image_responsive (version 6.6.0) :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Le filtre background_responsive accepte une troisième variable, $align (top, bottom, left, right) pour forcer le centrage de l’image ; avec la valeur focus, le plugin effectue le recadrage et le positionnement en fonction du « centre d’intérêt de l’image » déterminé par le plugin « centre_image ».

    Exemple d’utilisation :

    [(#LOGO_ARTICLE_NORMAL|background_responsive{480/800/1280/1920, 0, focus})]
  • Publier un message sans prévisualiser

    Avant de publier un message de forum, SPIP impose de le prévisualiser. Ce plugin permet de publier sans passer par l’étape de prévisualisation.

    http://contrib.spip.net/Publier-un-message-sans-previsualiser

    Cette fonctionnalité est disponible nativement dans SPIP 3.1. Pour l’activer il suffit de renseigner la meta forums_forcer_previsu avec la valeur non, cf :

    http://zone.spip.org/trac/spip-zone/changeset/81016

    #spip_blog

  • Modif du filtre #SPIP |image_proportions, pour améliorer le comportement lié aux plugins image_responsive et centre_image (la modif est dans le #plugin image_responsive) :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/centre_image

    Dans la version précédente, on pouvait recadrer et zoomer dans une image en fonction du centre d’intérêt de l’image (détectée automatiquement ou corrigée manuellement dans l’espace privé). À l’usage, je me suis rendu compte que du coup, le centre d’intérêt qui est rarement au centre de l’image, se retrouvait au centre de l’image retaillée. Par exemple, si on a un portrait, le centre d’intérêt est entre les yeux ; si on recadre/zoome, on se retrouve avec les yeux au centre de l’image, du vide au-dessus des cheveux et le menton coupé.

    Le comportement dorénavant, avec le critère focus, est plus malin : si les yeux du portrait sont par exemple dans le tiers haut de l’image d’origine, avec le recadrage ils seront encore dans le tiers haut de l’image résultante (c’est l’idée, mais c’est pondéré sinon c’est exagéré). L’effet est bien meilleur, et les images plus dynamiques.

    Si on veut recadrer avec le comportement précédent, il faut utiliser le critère focus-center.

    Voici une boucle pour tester avec les images d’un article :

    <BOUCLE_documents(DOCUMENTS){0,10}{par hasard}{id_article}>
            [(#FICHIER|image_proportions{1,1,focus,2}|image_reduire{200})]
            [(#FICHIER|image_proportions{1,1,focus-center,2}|image_reduire{200})]
    </BOUCLE_documents>

    Et une copie d’écran :

    On voit que les portraits avec le nouveau réglage (image de gauche de chaque paire) sont plus dynamiques et plus « naturels » que le recadrage avec le script précédent (image de droite, avec le nouveau critère focus-center).

    • Bonjour
      Je viens d’avoir un comportement étrange avec le filtre image_proportions (peut être aussi que je l’utilise mal :
      [(#FICHIER|image_proportions{16,9}
      |image_responsive{360/480/600/800}
      |inserer_attribut{alt,[(#_contenu_article:TITRE|attribut_html|couper{80})]})]
      Contexte : utilisation dans un formulaire d’upload, tout se passe bien avec des images avec largeur inférieure à 3600px. De 3700 à 4000, la page article est vide. Au delà de 4000px, page blanche.
      J’ai fais beaucoup de tests (largeur/poids) et ce n’est pas une question de poids.
      Quand erreur, le fichier error_log : [29-Dec-2015 17:38:22 America/New_York] PHP Fatal error : Allowed memory size of 125829120 bytes exhausted (tried to allocate 30798801 bytes) in /home/gwadloup/public_html/plugins-dist/filtres_images/filtres/images_transforme.php on line 301

      Quand j’enlève image_proportions{16,9}, tout fonctionne bien.
      J’utilise aussi le plugin géodiversité.

      Bonne année
      Cécile

    • comme suggéré sur irc, tu peux appliquer un filtre |image_reduire{1500} avant ce filtre-ci ; c’est moins gourmand en mémoire que image_proportions, donc ça devrait passer (et visiblement ça passe).

  • #knacss, un micro #framework #css qui a du goût !
    http://knacss.com

    Un framework CSS simple et léger réalisé par l’équipe d’Alsacréation. KNACSS, c’est un peu comme une feuille de style CSS « reset » sur-vitaminée qui permet de commencer un projet à partir de zéro tout en tenant compte de bonnes pratiques générales (accessibilité, performance, #responsive webdesign).

    #lesscss #sass #opensource #alsacréation

  • Je viens d’installer un nouveau #plugin #SPIP : Fond d’écran pour l’espace privé
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/fond_espace_prive

    En fait, ça modifie surtout la page de login :

    (Dans l’espace privé, ça insère aussi l’image, mais extrêmement éclaircie. J’ai commencé le plugin sur cette idée, mais je ne suis pas certain que ce soit une bonne idée, je crains que ça fatigue plus qu’autre chose.)

    L’image du phare (pour l’instant, ça peut changer…) est activée avec le plugin. On peut remplacer par l’image de son choix (je suggère une image de 1600 pixels de large), en installant un fichier du même nom dans IMG :

    IMG/fond_espace_prive.jpg

    Ça fonctionne en 3.0 et en 3.1.

  • Il ne faut plus mettre de jQuery du genre :

    $(function() {
    faire_un_truc();
    });

    dans la page Web elle-même. Parce que désormais, on peut (doit) charger les scripts en asynchrone, de façon à ne pas bloquer l’affichage de la page parce que les scripts ne sont pas encore arrivés.

    Du coup, si on met du jQuery directement dans la page, on a une erreur puisque jquery.js n’est pas encore chargé quand on fait l’appel au $.

    C’est notamment le cas avec des #plugins #SPIP, dont justement deux qui m’intéressent :
    – photoSwipe
    – varnish_stats

    Il faut passer tous les déclenchements dans des scripts séparés, quitte à ne conserver dans le corps de la page que des variables (dont la valeur serait connue uniquement dans grâce au squelette SPIP).

    (Je le ferais bien moi-même, mais mon SVN est tout cassé – j’ai eu l’idée saugrenue d’installer MacOS El Dorado sur ma machine.)

  • plugins.spip.net en 3.1

    Après le blog (cf
    http://blog.spip.net/SPIP-Blog-en-3-1-alpha-neo-dist.html), c’est au
    tour de plugins.spip de passer en SPIP 3.1. La mise à jour s’est bien
    passée, seules quelques petites adaptations ont été nécessaires sur les
    squelettes du site, cf :

    http://zone.spip.org/trac/spip-zone/log/_galaxie_/plugins-spip-net/svp2010

    N’hésitez pas à nous signaler tout comportement étrange ou bug du site
    observés depuis lundi 25 (date de la mise à jour).

    http://article.gmane.org/gmane.comp.web.spip.zone/37994

    #spip_blog

  • Seenthis, j’ai une question (avec application à #SPIP). Est-ce qu’il existe une méthode recommandée pour indiquer, dans le code HTML, les ressources liées à la page, sans pour autant entraîner le navigateur ou le preloadeur à charger des ressources inutiles ?

    Le besoin auquel je veux répondre, c’est la possibilité d’aspirer/dupliquer un site Web sans avoir des fichiers qui manquent une fois hors ligne. En effet, j’ai régulièrement des ressources chargées dynamiquement (ne serait-ce que mes images responsive), qui ne sont pas récupérées de manière transparente par une aspiration de la page.

    Pour l’instant, je m’en sors « à la main » en ajoutant des :

    <link href… rel="a_telecharger">

    dans mes pages. Ça permet de récupérer tout ce dont j’aurai besoin hors-ligne (ou potentiellement besoin, puisque je suis en responsive, avec souvent des éléments chargés ou non).

    Mais je n’ai pas systématisé ça sur mes sites en production (et notamment pas dans les plugins qui génèrent ces pages), parce que je ne veux pas que Google m’aspire des fichiers que je ne veux pas « fabriquer » ou « utiliser » rien que pour lui (par exemple, les images responsive jamais utilisées, je préfère qu’elles ne soient pas générées pour rien), parce que je ne veux pas que navigateurs les chargent (ni les pré-chargent) alors qu’ils ne vont pas les utiliser…

    Et en gros, s’il y a une méthode connue et/ou recommandée, voir à quel point c’est une pratique à documenter/généraliser dans SPIP, pour avoir des sites qu’on peut aspirer/sauvegarder/dupliquer en statique à coup sûr.

    Note : si on va par là (et j’aimerais bien que ce soit au moins une option), il y a aussi les problèmes de noms de fichiers. Il faut que certains plugins fonctionnent systématiquement en URL « .html », et pas en interminables variables PHP (par exemple, j’utilise des choses comme {ajaxload=html}), et/ou éviter d’ajouter la date à la fin des fichiers (CSS/logos) parce que ça me pète mon aspiration…

    • Autre question liée, est-ce que je peux mettre un <link> à l’intérieur d’un <a>, du genre :

      <a href="truc.html">Le contenu usuel du lien
          <link href="maressource.jpg" rel="resource"
      </a>

      Parce que dans de nombreux cas, la fonction qui fabrique les ressources (et donc les potentiels <link> à ajouter pour les aspirer) ne sait pas si ce qu’elle va produire se trouve à l’intérieur d’une ancre (je pense évidemment aux images responsive, dont le fonctionnement est totalement indifférent au fait d’être à l’intérieur d’un lien hypertexte).

    • Bon, je me lance avec une mise à jour assez conséquence de mon #plugin #SPIP image_responsive :
      http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

      On peut activer un define dans mes_options.php :

      define("_SPIP_LIER_RESSOURCES", true);

      (noter le choix d’un nom lié à SPIP et non au plugin, histoire de le réutiliser).

      Avec cette option, le plugin ajoute au code HTML généré une ribambelle de liens (qui n’affichent rien) de cette forme :

      <link href="truc.jpg" rel="attachment" property="url">

      (je suppose qu’on peut trouver mieux, mais comme pas trop de réponses à la question ci-dessus… et au moins avec ça le validateur-go-home arrête de m’engueuler).

      De cette façon, quand on aspire la page, on aspire aussi toutes les ressources qui seront nécessaire pour travailler en local.

      Avec image_responsive, évidemment, ça ne peut fonctionner que quand on définit une ou plusieurs tailles autorisées (ce qui est de toute façon un bon principe à la base).

  • Introduction d’un système de précalcul dans mon #plugin #SPIP image_responsive :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    On peut ajouter dans mes_options.php :

    define("_IMAGE_RESPONSIVE_CALCULER", true);

    Dans ce cas, à chaque fois qu’on a utilisé image_responsive en indiquant des tailles prédéterminées, le plugin va fabriquer les images responsive précalculées en /local/cache-responsive. Depuis le début, le plugin ne précalcule pas les images, mais se contente de retourner vers un script /action/image_responsive.php qui fabrique/cache/sert les images à la volée.

    Avantage du pré-calcul :
    – si utilisé sur tout le site, on pourra décider de désactiver le script action, et ainsi éviter de se faire remplir le cache local par un crawler qui déciderait de demander toutes les tailles (de 1 à 1000 par exemple) de toutes les images du site…
    – le gros avantage immédiat c’est de servir des fichiers image directement depuis Apache, et non plus des scripts PHP qui expédient des images ; je pense que ça allège le serveur, et que c’est sans doute plus rapide si on n’est pas derrière Varnish – mais j’ignore absolument dans quelles proportions.

    Inconvénients du pré-calcul :
    – toutes les tailles autorisées d’image sont immédiatement fabriquées ; une fois que toutes les pages du site sont calculées, on atteint illico la taille max utilisée par les images responsive (sans le pré-calcul, seules les images réellement réclamées par des visiteurs sont fabriquées). Sur un gros site avec beaucoup d’images, cette taille est potentiellement phénoménale…
    – les pages du site sont beaucoup plus lourdes à calculer la première fois, puisqu’il faut précalculer toutes les tailles de toutes les images (principe des filtres graphiques). Sur un site très graphique, ça peut être très important.

  • Je continue avec mon #plugin #SPIP image_responsive :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Dans la variable des proportions d’image, il est désormais possible d’utiliser des valeurs en pourcentage. Par exemple : 71%x0 va recadrer l’image à 71% de sa largeur, en conservant sa hauteur.

    |image_responsive{
            588/840/1280/1920,
            0,
            0,
            (max-width: 420px)/(min-width:421px) and (max-width: 700px)/(min-width:701px) and (max-width:1280px)/,
            71%x0/83%x0/0x0/0x0
    }
  • Grosse améliation de mon #plugin #SPIP image_responsive : il intègre désormais la gestion de la direction artistique, avec prise en compte (si l’on a envie) du centre d’intérêt automatique de l’image (avec le plugin centre_image :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    Il y a maintenant une variable supplémentaire (optionnelle), qui doit d’utiliser avec les valeurs de mediaqueries de la variable précédente. Par exemple :

    [(#FICHIER|image_responsive{
            600/800/1400,
            0,
            0,
            /(min-width:801px) and (max-width:1000px)/(min-width: 1001px),
            1x1xfocusx2 / 3x4xtop / 4x2
    })]

    Ici on a donc :
    – soit une image de 600 pixels de large, 800 pixels de large ou 1400 pixels de large
    – pas de lazyload (0)
    – pas d’alignement vertical (0)
    – l’image de 800 est utilisée pour les écrans de 801 à 1000 pixels de large, l’image de 1400 pixels pour les écrans de plus de 1001 pixels (OK, c’est pas dément comme choix…)

    La nouvelle variable contient 3 valeurs séparées par des / (avec ou sans espaces), qui correspondent aux valeurs de mediaqueries précédentes. Chaque valeur est de ce type :
    largeurxhauteurxalignementxzoom

    Les valeurs alignement et zoom sont optionnelles. Ces quatre valeurs correspondent aux variables de la fonction image_proportions :

    Du coup :
    – 1x1xfocusx2, image retaillée au carré (1x1), avec centrage sur le point d’intérêt (focus), et zoom de valeur 2 ; utilisé par défaut ;
    – 3x4xtop, image taillée en quatre tiers verticalement, découpe sur le haut de l’aime, et pas de zoom ; utilisé pour les écrans de 801 à 1000 pixels ;
    – 4x2, image deux fois plus large que haute, recadrage au centre par défaut, pas de zoom ; utilisé pour les écrans de plus de 1001 pixels de large.

    Par ailleurs, ici on a indiqué 3 valeurs correspondant aux 3 media queries. Mais on peut aussi n’utiliser qu’une seule valeur de recadrage, qui sera alors systématiquement utilisée pour toutes les tailles (et cela fonctionnera aussi, dans cas, même si on n’utilise pas les mediaqueries).

    Plusieurs intérêts :
    – pouvoir utiliser des formats d’images différents selon les tailles d’affichage, et/ou orientations d’écran,
    – affiner ces recadrage en utilisant le centre d’intérêt automatique de l’image,
    – pouvoir zoomer dans l’image selon la taille d’affichage, éventuellement en centrant sur le point d’intérêt de l’image.

  • Évolutions de mon #plugin #SPIP image_responsive
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    – v5.1 : transparent pour l’utilisateur (sauf bug…), lorsqu’on utilise les fonctionnalités avancées qui fabriquent un srcset ou des <picture><source>, ce n’est plus mon javascript perso qui va gérer les remplacements d’images, mais le polyfill picturefill.js, plus puissant. (C’est en préparation à l’automatisation de l’ajout de la « direction artistique », qui demandera à utiliser les <source> au lieu d’un simple remplacement d’image proportionnelle ;

    – v5.2 : ça devient carrément marrant : ajout d’une quatrième variable à image_proportions, qui indique un niveau de zoom. Par exemple :

    [(#FICHIER|image_proportions{200,200,focus,2})]

    si cette valeur (ici : 2) est supérieure à 1 (en pratique : 1.2, 1.5…), alors le recadrage se fera en zoomant à l’intérieur de l’image. Si on a indiqué comme ici « focus », alors on zoome vers le centre d’intérêt de l’image
    (on n’est pas obligé de faire ça sur « focus », ça fonctionne aussi avec les autres types de recadrage).

    • Pour tester :

      <html>
      <body>

      <BOUCLE_documents(DOCUMENTS){0,10}{par hasard}{inverse}{extension=jpg}>
      <div>
              <div style="position: relative; display: inline-block;">
              [(#FICHIER|image_reduire{200})]
             
                      <div style="position: absolute; margin-left: -7px; margin-top: -7px; left: [(#FICHIER|centre_image_x|mult{100})]%; top: [(#FICHIER|centre_image_y|mult{100})]%">
                      <img src="[(#CHEMIN{imgs/croix.png})]">
                      </div>
             
              </div>
              [(#FICHIER|image_proportions{0,0,focus,2}|image_reduire{200})]
              [(#FICHIER|image_proportions{200,200,focus,2}|image_reduire{200})]
              [(#FICHIER|image_proportions{200,200,center, 2}|image_reduire{200})]
      </div>
      </BOUCLE_documents>

      </body>
      </html>
    • (Il faut donc maintenant que j’intègre tout ça directement dans la fonction |image_responsive. Ensuite il faudra bien qu’on ait une fonction pour corriger les centres d’intérêt des images, parce qu’avec le zoom, les erreurs deviennent bien plus pénibles.)

  • J’ai commencé un nouveau #plugin pour #SPIP : centre_image
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/centre_image

    Après installation (PHP 5 au minimum : on a besoin de la fonction image_filter), on se retrouve avec 3 filtres qui s’appliquent à des images :
    centre_image($fichier) retourne un tableau array{x,y} du centre d’intérêt de l’image,
    centre_image_x($fichier) et centre_image_y($fichier) sont plus directement utilisables dans les squelettes, puisqu’ils retournent indépendamment la valeur x et la valeur y de la fonction précédente.

    x et y sont des valeurs entre 0 et 1 (x à 0 à gauche, 1 à droite ; y à 0 en haut, 1 en bas), qui donnent les coordonnées du « point d’intérêt » de l’image, calculé automatiquement sur le principe de l’« entropie ».

    Quelques éclaircissements :

    – un problème classique quand on recarde une image automatiquement, c’est que selon la nature de l’image, on n’obtient pas un recadrage pertinent (têtes coupées parce qu’on a visé trop bas, statue hors cadre parce qu’on a coupé au centre…) ; du coup, je viens déjà d’introduire un réglage automatique dans la fonction image_proportions livrée dans le plugin image_responsive (version 5.0 à l’instant) :
    ``image_proportions($img, 16, 9, "focus")``
    là où l’on pouvait déjà indiquer top, left… si on indique focus, alors l’image sera recadrée en fonction du résultat du nouveau plugin ;

    – une difficulté que je veux régler, c’est l’utilisation de grandes images en fond de page : quand on écrit la tritraille dessus, on fait dans le systématique, et du coup ce n’est pas forcément le plus heureux ; avec ce plugin, on peut décider que si le point d’intérêt de l’image est à gauche, alors on installera la titraille à droite sur l’image (et inversement) ;

    – une orientation que je veux développer pour le plugin image_responsive (d’où le passage en version 5) : faciliter et automatiser la « direction artistique », c’est-à-dire la possibilité d’afficher une version zommée sur le point d’intérêt de l’image quand on l’affiche en petit ; si je connais le « point d’intérêt » avec l’autre plugin, une partie du boulot est déjà fait…

    – le gros hic, c’est que la méthode fonctionne couci-couça (mais vu le but, je pense que c’est très acceptable : avant on coupait ou on plaçait les éléments carrément au pif)… la prochaine étape du développement va consister à donner des outils pour que le webmestre puisse, d’un clic, « forcer » le placement du point d’intérêt.

    • Un petit squelette pour tester sur des documents pris au hasard sur ton site :

      <html>
      <body>

      <BOUCLE_documents(DOCUMENTS){0,10}{par hasard}{inverse}{extension=jpg}>
      <div style="position: relative; float: left;">
      [(#FICHIER|image_reduire{200})]

              <div style="position: absolute; margin-left: -7px; margin-top: -7px; left: [(#FICHIER|centre_image_x|mult{100})]%; top: [(#FICHIER|centre_image_y|mult{100})]%">
              <img src="[(#CHEMIN{imgs/croix.png})]">
              </div>

      </div>
      </BOUCLE_documents>

      </body>
      </html>
    • @speciale : comme tu le vois, si tu passes par |mult{100}%, tu obtiens bien des pourcentages. J’ai préféré la vieille méthode du pseudo-pourcentage en stockant directement la valeur entre 0 et 1 (0.35 est égal à 35%), parce qu’avec des vrais pourcentages, il faudrait que je stocke aussi le symbole % dans la variable, et là c’est super-lourd derrière (si tu veux faire des manipulations mathématiques, tu dois alors d’abord virer le symbole de pourcentage…)

    • Sympa, je l’ai testé avec le petit squelette suivant et une sélection d’images déposées dans squelettes/images :

      <h1>dans ta face !</h1>
      <BOUCLE_ls(DATA){source glob,  #CHEMIN{images}/*.jpg}>
      [(#VALEUR|image_reduire{150})]
      [(#VALEUR|image_proportions{1,1,center}|image_reduire{150})]
      [(#VALEUR|image_proportions{1,1,focus}|image_reduire{150})]
      <hr />
      </BOUCLE_ls>

      J’ai bien fait attention à utiliser des images où « le centre d’intérêt » était déporté dans un coin et jamais au centre, et le résultat était souvent bon. Le squelette de test affiche l’image originale réduite à 150 px, puis la même « recadrée » au centre et enfin une version recadrée #automagiquement sur le focus. Du coup, cela permet de mettre en évidence l’action de l’argument focus par rapport à un recadrage au centre.

      Idée, je pense que ça serait sympa d’intégrer la fonction image_proportions dans le plugin filtres images du core (elle y a sa place amha). Et puis, cela permettrait aux personnes qui le souhaitent de jouer avec centre_image sans installer image_responsive. Tu en penses quoi @arno ?

      #spip_blog #merci :)

    • yep @b_b et @arno, je suis d’accord, je l’ai dit plusieurs fois : ça commence à faire un certain temps maintenant qu’on a nos fonctions d’images dans un plugin bien propre séparé du core (et fourni en dist), donc pour moi TOUTES les fonctions d’images intéressantes devraient s’y trouver, une fois qu’on les a un peu testé. D’après moi ça n’a pas de sens d’avoir plusieurs plugins différents comme « conteneur » de fonctions d’images (sur la zone/contrib il y avait un plugin de fonctions supplémentaires comme ça). On balance tous les trucs utiles dans le plugin commun.

      @nidal j’avais commencé un tout début de truc, mais jamais eu le temps de le faire en entier parce que sur mon temps libre j’essaye de ne pas coder. :)
      Mais je l’ai toujours en tête, et j’en ai même reparlé dans le cadre un projet pro cette semaine…

      Je ne pense pas que ce soit un truc énorme à faire, peut-être une idée d’atelier en plus pour la rencontre de Toulouse dans 3 semaines.

    • @b_b : je suis d’accord. La difficulté, c’est de savoir ensuite comment on continue à faire évoluer ces fonctions une fois qu’elles sont dans le core. (La dernière fois que j’ai voulu intervenir dans un plugin_dist, on m’a annulé ma modif en me renvoyant à des séries de tests à valider et tout et tout. Autant dire que ça me fait chier si c’est pour retourner là-dedans.)

      Après, en l’occurence, on a spip_proportions stable et bien pratique qu’on pourrait sans difficulté ajouter au core. Mais là il s’agit d’intégrer dedans la fonctionnalité « focus », qui est carrément expérimentale. Je ne sais pas trop comment on gèrerait ça.

    • @arno ça pourrait pas être géré à base de pipeline(s) ? La fonction image_proportions (générique, dans le noyau) pourrait avoir un pipeline quand on est dans le cas « focus ». Quand y a rien de spécial, ça prendrait le centre par exemple, mais un plugin pourrait s’insérer dedans et définir X et Y. Cette fonction n’aurait pas à connaître qui peut venir changer ça. Et ce serait donc au plugin centre_image de s’insérer dans le pipeline et de définir X et Y suivant sa méthode. Un truc comme ça.

      Après on peut aussi se dire qu’il n’y aura toujours qu’une seule manière de trouver un centre de manière automatique, et qu’il y ait une fonction unique (non existante par défaut) qui peut être définie (par un autre plugin donc) et quand elle est définie ça l’utilise pour sortir X et Y.

      Mais bon pipeline ou fonction unique, le principe reste le même : « image_proportions » doit juste permettre de s’y insérer (dans le cas « focus » tout du moins), en donnant l’image en question et en permettant de renvoyer un X et un Y.

    • Yo @arno, je viens de voir que tu viens de commiter un ajout pour permettre la définition explicite manuelle du focus d’une image : Allelujah ! :D

      Du coup ça correspond tout à fait au plugin « Focus » que j’avais mollement commencé et dont je parlais. Si ton plugin peut bien être utilisé de manière tout à fait autonome, c’est vraiment ça.

      Par contre je ne comprenais pas où tu stockais les coordonnées du focus. Mais après lecture, il semblerait que tu les gardes dans un fichier JSON contenant le MD5 de l’image, c’est ça ?

      Du coup, en plus d’être utilisable pour les images « spip_documents » avec l’ajout d’interface que tu as fait, c’est potentiellement utilisable aussi pour d’autres images non-"spip_documents", c’est ça ? (Bon ce sont des cas plus rares hein, mais c’est toujours bien de le savoir.)

      #merci !

    • @rastapopoulos : exactement, ça se base « bêtement » sur l’URL du fichier. Dans l’espace privé, ça récupère toutes les images qui ont un lien .hasbox et un type image/…. Et j’ai ajouté l’exclusion sur les images qui sont intégrées à l’intérieur des articles, sinon ça se met à déconner (à cause des doublons).

    • Attention : la nouvelle version réclame qu’on utilise la dernière version du plugin-dits medias, et mon plugin contient des motifs pour forcer l’affichage des images de portfolio en grand (150 pixels de large, et non plus les minuscules trucs de 60 pixels).

      C’est assez contraignant pour l’instant, en attendant qu’on modifie le comportement natif de medias (j’ai demandé à le faire ce matin, mais aucune réponse sur spip-dev).

      Dans l’interface privée, un javascript va attaquer les logos et les documents joints :

      Sur la seconde image, on voit bien la différence avec l’actuel : les vignettes sont de très bonne taille (ça donne une impression d’interface carrément plus moderne).

      Le javascript récupère chaque image, et à chacune ajoute un petit cadre vert (indiquant que le centre d’intérêt est chargé), et une croix à l’endroit du centre d’intérêt automatique.

      Si on veut corriger, c’est immédiat : on prend la croix, on la fait glisser vers le centre d’intérêt et voilà, c’est corrigé. Je vois pas comment faire plus simple.

    • Autre question : le filtre « image_recadre » du noyau sait aussi prendre en entrée un ratio maintenant ("3:2, +").
      (Et du coup image_proportions est-il d’ailleurs toujours pertinent, peut-être vaut-il mieux mutualiser puisque la fonction du noyau sait déjà le faire.)

      Mais du coup il manque le fait de pouvoir donner des pourcentages (ceux de centre_image) dans le troisième argument $position, il me semble, c’est ça ? (Car je crois que ça ne connait que top, left, etc.)

      Et un corollaire : dans ce genre de recadrage, si on donne le point de focus, c’est pour qu’il soit « à peu près » au centre une fois le recadrage terminé. Mais suivant où il est placé, ce n’est pas forcément pile au centre. S’il est proche d’un bord, ben ça doit s’arrêter au bord.

    • C’est assez contraignant pour l’instant, en attendant qu’on modifie le comportement natif de medias (j’ai demandé à le faire ce matin, mais aucune réponse sur spip-dev).

      ( je ne vois pas ton message sur spip-dev)

    • Oui, je suppose qu’il faudrait aussi améliorer image_recadre, mais encore une fois c’est une question pratique : image_proportions est chez moi et je peux le patcher instantanément. Dans le core je ne sais plus trop si j’ai le droit de patcher ou si je vais me faire jeter.

      Pour ta dernière remarque, oui c’est pris en compte : on recadrer au plus proche du centre d’intérêt, mais ça ne va pas forcément le placer au centre si ce point est près du bord. Mon code qui fait ça n’est pas d’une compacité folle, c’est parce que ça laisse la logique mathématique plus visible comme ça :-))

    • Ah et aussi en rapport : ce plugin jQuery qui recadre en javascript suivant le focus de chaque image (qu’on précise dans le code de l’image) :
      http://seenthis.net/messages/289821

      Cela peut être complémentaire pour générer moins d’images, et aussi pourquoi pas pour définir les hauteurs d’images en « em » afin d’être alignées sur la grille typo et les largeurs sur la grilles des colonnes (qui peut être en %), et donc pas toujours la même proportion suivant l’écran.

    • @rastapopoulos : j’ai un script remplir_image.js qui fait ça aussi. Mais l’avantage avec image_proportions et les nouvelles subtilités d’image_responsive (et <picture>), c’est qu’on n’attend plus sur javascript pour charger et afficher les images. Avec Chrome pour l’instant (et Firefox le mois prochain), c’est incroyablement plus réactif que quand on compte sur jQuery pour faire des calculs et des affichages.
      http://seenthis.net/messages/264068

    • @arno pour le core, logiquement, tu as le droit de patcher tant que ça ne casse rien à l’existant.

      Si on veut faire « propre », je crois qu’il y a deux méthodes pour ça :

      – Soit la fonction a une batterie de tests unitaires. Et donc tu peux modifier dans la branche stable (3.0), tester si ça renvoie toujours les bons trucs pour les anciens comportements, et si tests ok, commiter. Si on part du principe que les tests unitaires sont complets, alors tant que ça renvoie ok, toute modif peut être commitée sans danger.

      – Soit ya pas de tests, ou bien tu n’as pas le temps de comprendre comment les faire tourner (hihi). Dans ce cas, tu peux modifier dans la branche dev (3.1) ! Tu testes sur tes cas à toi (pas les tests unitaires normalisés du coup), et si tu penses que c’est bon, tu envoies en 3.1. Du coup c’est public et tu peux demander à d’autres de tester ton ajout. Si plusieurs personnes pensent que c’est bon (ou que personne ne répond pendant longtemps :D) : tu reportes ta modif dans la branche stable (3.0). Un « backport ».

      Ça ce sont les deux manières qui normalement devraient toujours marcher. Sinon c’est pas gentil. :)

      Après, au-delà, il est possible aussi de commiter directement en 3.0 sans tests unitaires, et reporter en 3.1 (c’est moins logique mais c’est logique quand on est dans un projet réel qui utilise la stable !). Là faut juste être sûr de soi, de ne rien casser.

      Enfin, mon avis purement personnel est que ce serait super que tu améliores image_recadre du noyau avec ces ajouts (notamment le fait de pouvoir lui passer les coordonnées précises), et que ça soit ainsi mutualisé dans un seul endroit (le plugin d’images du noyau, commun à tou⋅te⋅s).

    • Un truc qui me questionne : je vois que ça enregistre les coordonnées calculées ou forcées dans local/ ... du coup, si on vide le cache des images, on perd les coordonnées qu’on avait forcées à la mano en déplaçant la croix ?

      Est-ce qu’il ne vaudrait pas préférer, si on est dans le cas d’un document eregistré dans la table spip_documents, ajouter 1 ou 2 champs pour stocker les coordonnées ?

    • Là l’avantage c’est que ça marche pour n’importe quelle image, même quand c’est pas un document SPIP (les logos par exemple, mais ça pourrait être d’autres choses).

      Mais par contre oui, l’emplacement des JSON posent clairement un problème : une vraie information pérenne ne DOIT PAS se placer dans un dossier temporaire. :D

      Pour rappel, SPIP à 4 dossiers variables : 2 fixes, et 2 temporaires. Et dans le même temps : 2 accessibles, et 2 inaccessibles.

      Les noms des dossiers sont très mal choisis mais restent là par compatibilités. Mais dans le code les noms sont beaucoup plus clairs et logiques :

      – permanent_accessible : IMG
      – permanent_inaccessible : config
      – temporaire_accessible : local
      – temporaire_inaccessible : tmp

      En conséquence, les infos de positions sont permanentes, et accessibles. Et donc si on ne veut pas les enregistrer en base, mais dans des fichiers, alors elles devraient aller dans IMG, pas dans local.

    • @marcimat non non : image_recadre fait déjà les proportions (et je l’utilise régulièrement). Donc pas besoin d’ajouter une fonction pour ça à mon avis.

      Au lieu de faire |image_passe_partout|image_recadre maintenant je fais |image_reduire{taille maximum que je veux}|image_recadre{16:9,''}.

      Mais ce qu’il faudrait du coup, c’est améliorer image_recadre qu’on a déjà, pour lui intégrer la possibilité de définir le centre manuellement et précisément dans l’un de ses paramètres.

    • Ce plugin m’intéresse particulièrement en conjonction avec le plugin image_responsive, plus précisément dans ce qui était décrit dans le premier post avec la fonction image_proportion.
      Cependant,
      #FICHIER|image_proportions{16,9,"focus"}|image_responsive{320/640,1,0}
      avec ou sans guillemets à focus, ne semble rien donner de manière automatique. Si l’on définit le focus de l’image, cet argument semble inutile.
      Je suis en SPIP 3.0.20, Filtre image_responsive en 6.4.1 et Centre image en 0.5.1.

      Merci pour tous ces plugins et pour le coup de main :)

    • J’ai ajouté en SPIP 3.1, en espérant ne rien n’avoir cassé, la possibilité d’utiliser le centrage avec la fonction |image_recadre, du plugin fonctions_images qui est fourni par défaut avec SPIP

      Donc, on activant ce plugin, sans forcément avoir le plugin image_responsive, on peut utiliser des recadrages en centrant sur le point d’intérêt, de la sorte :

      [(#LOGO_ARTICLE|image_recadre{16:9, -, focus})]

      ou encore, pour avoir une taille spécifique

      [(#LOGO_ARTICLE|image_recadre{200:80, - focus}|image_reduire{200, 80})]

      Il y a aussi focus-center comme dans image_proportions.

    • J’ai une question : je viens de rajouter une invalidation du cache (http://zone.spip.org/trac/spip-zone/changeset/97747) pour pouvoir voir l’effet d’un changement du point d’intérêt immédiatement.
      Du coup, j’ai étudié un peu le code et j’ai été sidéré de voir qu’au lieu de sauvegarder dans la base, c’était un fichier .json qui était créé pour enregistrer la position du point d’intérêt.
      Qu’est-ce qui a présidé à ce choix technique ?

    • Je me suis fait une fonction sympa :

      // Permet de recadrer une image en la centrant sur son focus
      function focusimage($img, $largeur, $hauteur, $position = 'center') {
              if ((largeur($img) <= $largeur) AND (hauteur($img) <= $hauteur)) {
                      $img = image_recadre($img, "$largeur:$hauteur", '+', $position, 'transparent');
                      $img = image_recadre($img, $largeur, $hauteur, $position, 'transparent');
              } else  {
                      $img = image_recadre($img, "$largeur:$hauteur", '-', 'focus', 'transparent');
                      $img = image_reduire($img, $largeur, $hauteur, $position, 'transparent');
              }
              return $img;
      }

      Et si l’image est plus petite, elle est affichée au centre par défaut, mais on peut indiquer sa position.

    • Merci pour ce plugin qui s’avère rapidement être indispensable.
      Une chose à préciser dans une éventuelle future documentation (c’est peut-être mentionné dans le fil de discussion mais j’ai pas tout relu) : le point d’intérêt n’est pris en compte que si le filtre image_recadre est appliqué en premier à l’image.

      Ceci fonctionne :
      [(#LOGO_PATATE|image_recadre{4:3, -, focus}|image_machin|image_truc)]

      Mais pas cela :
      [(#LOGO_PATATE|image_machin|image_truc|image_recadre{4:3, -, focus})]

    • Oui et on disait avec @marcimat que peut-être ça pourrait être bien de garder en mémoire cette info au fil des modifs d’une image OU de garder en mémoire la toute première image source quand il y a une suite de filtres d’images d’affilée, et SI la dernière chose avant le « recadre » a les mêmes dimensions que l’image d’origine, alors on peut recadrer avec le même centre, même 12 filtres plus loin.

      Bon, en attendant, faut bien le mettre en premier…