• Lancement aujourd’hui de la nouvelle maquette d’Orient XXI (@orientxxi, #shameless_autopromo donc) :
    https://orientxxi.info

    Évidemment c’est du pur #SPIP, et un aspect était d’assurer la continuité sans douleur avec les 2000 articles déjà publiés sur ce magazine. Boulot graphique affiné avec @diala. Travail sur la structure éditoriale avec Michel Raffoul.

    Notre premier axe a été de travailler la lisibilité des pages d’articles. Les articles d’Orient XXI étant longs, c’est l’aspect primordial de la maquette. J’ai choisi la police Lora, que je trouve très lisible à l’écran, avec une certaine légèreté dans le gris typographique :
    https://fonts.google.com/specimen/Lora
    Avec un critère important : une italique joliment dessinée, clairement différenciée, et très lisible.

    Pour faire le contraste, les éléments de navigation du site utilisent la police Raleway de The League of Movable Type :
    https://www.theleagueofmoveabletype.com/raleway
    utilisée en capitales, et en jouant sur une opposition marquée entre une version très grasse (black) et une version plutôt maigre (regular).

    Pour la maquette du texte, le choix désormais classique d’une colonne unique, au maximum 700 pixels de large, et un corps de texte courant assez massif (environ 21px sur grand écran). L’idée étant, encore une fois, de privilégier le confort de lecture de textes longs. (Références : Medium.com, le mode « Lecteur » de Safari, et lecture Zen du Monde.)

    Parmi les petites astuces dans les articles :
    – les notes de bas de page s’affichent en colonne de droite quand on clique sur le numéro d’appel de note,
    – un calcul un peu rigolo pour insérer à l’intérieur du corps du texte un bandeau d’inscription à la newsletter,
    – les liens hypertexte vers l’extérieur ont un graphisme plus nettement différencié des liens internes,
    – la maquette des intitulés des images, en dehors de la colonne de texte (parfois à côté de l’image, parfois sous l’image quand elle-même dépasse de la colonne de texte).

    Autre aspect important sur les pages d’article : l’entrée de page est travaillée pour introduire rapidement la lecture : titre, chapeau, chemin de fer, boutons de partage, tout ça massif mais « above the fold ».

    L’idée est de donner une impression de magazine, et non de quotidien. Ce qui donne des choix graphiques et tygraphiques forcément différents.

    Pour le bandeau de navigation de haut de page :
    – refonte du logo (l’emblème rond n’est pas de moi),
    – petit jeu du menu qui se « décroche » en version plus compacte, et qui redevient visible quand on scroll vers le haut (désormais classique, mais efficace je trouve),
    – menu de navigation dont deux éléments ont un sous-menu. Ce menu passe dans le hamburger sur petit écran et sur système qui ne gère pas le survol).

    Au niveau de la structuration du site, très gros changement : la structure par rubriques est remplacée par une structure thématique et par pays. Cela repose certes sur les mots-clés de SPIP, mais les « thèmes » et les « continents » ne sont ni des mots-clés SPIP ni des groupes de mots-clés :
    https://orientxxi.info/outils/selections/les-pays/pays-du-levant,2316
    Ce qui permet à la fois des thémes qui se croisent, et une sorte de fil d’ariane sur les mots-clés un peu plus profond qu’avec l’outil classique de SPIP (par exemple : Pays > Pays du Golfe > Bahreïn) tout en réutilisant la thématisation manuelle des 2000 articles déjà publiés :
    https://orientxxi.info/fr/bahrein

    La page d’accueil essaie de mettre en avant plus de contenu, avec des calculs un peu sympas pour savoir quels grands thèmes mettre en avant en fonction de l’actualité des publications.

    Systématisation de l’utilisation de mon plugin « Centre d’intérêt d’images » :
    https://www.paris-beyrouth.org/Plugin-centre_image
    qui permet d’indiquer directement dans l’espace privé le point « central » d’une image et de faire plein de recadrages différents sans couper n’importe comment.

    Toujours sur la page d’accueil, une sorte de « player vidéo » qui présente toutes les vidéos directement là, sans changer de page. Assez rigolo à faire.

    Travail sur les pages d’auteurs, avec autant que possible utilisation de photos des auteurs :
    https://orientxxi.info/fr/auteur/alain-gresh

    La récupération du flux Seenthis d’@OrientXXI est toujours là :
    https://orientxxi.info/au-fil-du-web
    qui permet de publier un suivi d’actualité de manière vraiment simple.

    On conserve également mon outil qui permet d’animer simplement des illustrations :
    https://orientxxi.info/va-comprendre/pourquoi-les-etats-unis-cessent-ils-de-financer-l-agence-des-nations-uni

    Converser également cette possibilité, largement utilisée sur les articles historiques du site, d’installer de grandes images en haut de page, avec un jeu de dégradé, ce qui donne un aspect très « magazine » :
    https://orientxxi.info/lu-vu-entendu/le-canal-de-suez-un-enjeu-toujours-actuel,2557

  • Time-saving #CSS techniques to create #responsive #images
    https://medium.freecodecamp.org/time-saving-css-techniques-to-create-responsive-images-ebb1e84f

    To Recap

    1) Use background-image if your image is not part of the page’s content.
    2) Use object-fit if you don’t care about IE.
    3) The padded container technique, used by Netflix, works everywhere.
    4) In most cases, just add height: auto; in your CSS.
    5) If you need fast load times, use srcset to load smaller images on mobile.

  • Nouveau #plugin #SPIP : Fonds d’articles
    https://zone.spip.org/trac/spip-zone/browser/_plugins_/fonds

    C’est un plugin particulièrement important dans les sites que je réalise désormais, parce qu’il me permet d’installer les images qui viendront se fondre sous le texte de l’article, ce qui constitue un aspect central de mes #longforms avec SPIP.

    Par exemple :
    – dans les dossiers histoires d’Orient XXI :
    http://orientxxi.info/l-orient-dans-la-guerre-1914-1918/german-asymmetric-warfare-in-world-war-i,1423
    – les articles d’Orient Palms :
    http://fr.orientpalms.com/L-oeil-de-Tony-Hage
    – la page d’accueil de Paris-Beyrouth :
    http://www.paris-beyrouth.org
    – les « formes longues » du site de l’OPPIC :
    http://www.oppic.fr/rubrique18.html
    – bien entendu, ma spectaculaire démonstration à base d’images de la NASA :
    http://www.orientpalms.com/demo/spip.php?rubrique2

    Le principe est de créer des images se terminant par un dégradé vers un aplat de couleur (de la même couleur que le fond de la page, que l’on indiquera aussi dans l’interface du plugin), puis d’installer cette image en « fond » d’article, une partie se trouvant avant le pavé de texte, et la seconde (la partie peu contrastée) en dessous du pavé de texte. Le plugin permet d’installer de telles images en haut et en bas de l’article. D’autres options permettent d’installer une image « en fond » d’article, sans notion de haut et de bas.

    Par ailleurs, l’affichage est responsive, avec un balisage moderne qui autorise le pré-chargement des images et l’affichage adapté sur écran haute définition.

    • Pour créer l’effet de dégradé ci-dessus…

      (1) Je pars de l’image d’origine (celle-ci n’est pas très grande, je préfère si possible travailler avec des images de 2400 pixels de large, pour couvrir les besoins d’un écran haute définition de type iPad) :

      (2) Dans mon logiciel de dessin, je déterminer (avec des règles bleues ici) comment découper mon image :


      – La partie supérieure du ciel sera ici supprimée.
      – La partie centrale sera la partie qui apparaîtra au-dessus de la zone de texte : on n’écrira donc pas sur cette partie (par choix graphique, et parce que c’est une image trop contrastée pour que du texte qui soit lisible).
      – La partie inférieure sera la partie sur laquelle on commencera le bloc de texte : on écrira donc « par dessus » cette partie, qui devrait être faiblement contrastée.

      (3) Étape particulièrement importante : j’applique un dégradé vers une couleur d’aplat (qui correspondra à la couleur de mon fond d’article) sur la partie basse de l’image :

      (4) Je découpe l’image en deux parties :

      Je sauvegarde ces deux images (img_haut.jpg et fond_haut.jpg par exemple) sur mon disque dur.

      (5) Je me rends dans l’espace privé de mon site, sur l’article qui convient, et je trouve en colonne de droite, l’encadré suivant :

      Les deux intitulés qui m’intéressent sont : « Image du haut », où je vais installer img_haut.jpg, et « Dégradé du haut » où j’installe fond_haut.jpg. Je peux uploader via « Enregistrer », mais ici, je vais cliquer plutôt sur la pipette.

      Et hop… Cela donne directement une vue réduite de la page :

      La pipette a indiqué que je voulais extraire automatiquement la couleur en bordure bas de l’image. Si le résultat automatique ne convient pas, je peux évidemment renseigner le code de la couleur à la main. (Et à l’inverse, si j’ai oublié de passer par la pipette pour uploader les images, je peux simplement cliquer sur la pipette une fois les images déjà chargées, ça fonctionnera aussi.)

      Si nécessaire, j’effectue la même opération pour le bas de l’article.

    • On peut tout à fait n’installer qu’une image de haut, ou qu’une image de dégradé du haut, ou la même chose en bas, selon la nature des images qu’on utilise. Toute la difficulté, c’est de bien prévoir à quel endroit on accepte ou on interdit de placer le texte par dessus l’image, avant tout par souci de lisibilité.

      Un autre usage très simple consiste à ne même pas utiliser d’image, ni en haut ni en bas, mais à simplement choisir une couleur de fond d’article.

    • Au niveau des squelettes, il faut modifier son squelette d’article pour appeler fonds_article.html, par exemple :

      [(#INCLURE{fond=fonds_article}{id_article})]

      Ce squelette gère l’ajout des images. En revanche, c’est toujours à vous de créer le squelette d’affichage du bloc de texte de l’article (contenant le texte, mais aussi le titre, le sous-titre, et tout ce que vous voulez…).

      De manière automatique, le squelette du plugin essaiera de charger un squelette : inc/contenu-article.html

      mais vous pouvez aussi lui passer un autre nom de squelette, que vous passerez dans une variable contenu_article :

      [(#INCLURE{fond=fonds_article}{id_article}{contenu_article=inc/mon_squelette_a_moi)]

      Oui, c’est un peu brut de décoffrage, il va falloir bosser un peu de votre côté…

    • Ah, un détail mignon : sur écran de petite taille (smartphone, tablette verticale), les images sont recadrées automatiquement, on conserve tout leur contenu vertical, mais on supprime une partie de la droite et de la gauche de l’image. De cette façon, sur petit écran, on limite l’aspect « minuscule bandeau horizontal », en « zoomant » un peu par rapport à l’image d’origine.

    • Quelques remarques :

      – d’expérience, ce n’est pas évident du tout à utiliser ; pas techniquement (une fois qu’on a réussi à bidouiller les squelettes), ni de l’interface, mais surtout au niveau graphique ; si on n’a pas de solides compétences de graphisme (et si on ne sait pas bien utiliser un logiciel de manipulation d’images), on n’y arrivera pas ;

      – du coup : ça réintroduit un graphiste dans la mise en ligne des articles. (Je te laisse réfléchir à ça…)

      – réaliser les images du haut avec des dégradés est généralement beaucoup plus difficile que de créer les images du bas de l’article. Avec les images du haut, on est généralement coincés par le corps des gens, sur lesquels on ne peut pas facilement appliquer de dégradé de couleur… avec les images du bas, on a souvent le ciel ou le plafond, c’est nettement plus facile (mais moins spectaculaire puisqu’on ne le voit qu’après avoir scrollé tout l’article)

      – par ailleurs, il faut essayer de faire des images « du haut » (au-dessus) du texte très larges et pas trop hautes, c’est-à-dire de grands bandeaux très horizontaux, puisque sinon on va rejeter le texte après l’image, possiblement en dehors de l’écran ; ça ajoute encore de la difficulté dans la création des images de fond du haut de l’article (alors que, en bas de page, on n’a aucun problème à avoir une image très haut).

    • Le plugin permet aussi de gérer une image en fond d’article (ni en haut, ni en bas, « en fond »…). Cela se passe dans la partie basse de l’interface :

      On chargera donc une image dans « Image de fond », qui devra s’afficher sous le bloc de texte de l’article.

      Il y a alors trois options pour dimensionner ce bloc de texte :

      taille automatique, le bloc aura naturellement la taille fabriquée par son contenu ; c’est l’image qui tentera de s’adapter aux dimensions du bloc de texte (donc de manière potentiellement grotesque) ;
      remplir l’écran, le bloc aura la hauteur de la fenêtre du navigateur ; si nécessaire, le plugin ajoutera de l’espace en haut et bas du texte pour centrer le texte dans l’écran, ou au contraire provoquera un ascenseur vertical (pas dément). C’est surtout destiné à un texte très court. Et c’est excessivement difficile à maîtriser, à cause des grandes différences de tailles d’écrans ;
      proportions de l’image : fabriquer un bloc de la « taille » de l’image affichée sur toute la largeur de l’écran ; on ne cherche pas à « remplir » l’écran, mais à afficher toute l’image. Comme précédemment, c’est destiné aux textes courts, ça ajoute du blanc ou ça ajoute des ascenseurs selon la hauteur du bloc de texte, mais c’est généralement plus facile à maîtriser…

      Dans le cas de remplir l’écran, par défaut le plugin affichera l’image en « position : fixed », l’image s’affichera avec cet effet de « parallaxe » (qui personnellement me sort désormais par les oreilles…), c’est-à-dire un élément qui ne scrolle pas pendant que le reste de la page défile.

    • Et une dernière technique : si tu fais ça en haut et bas d’articles, et que tu affiches tous les articles d’une rubrique les uns après les autres dans la même page, tu obtiens un énorme… longform. Et c’est comme ça que j’ai fabriqué ma démo de la Nasa. (Ou, moins « fondue » graphiquement, la page d’accueil de Paris-Beyrouth.)

      Dans le cas de la Nasa, toute la difficulté consiste à découper les images pour que le bas de l’article se « fonde » pour devenir le haut-dégradé de l’article suivant, et qu’on ait ainsi une impression de passage d’un article à l’autre avec une même grande image dégradée vers le haut et vers le bas. C’est pas évident à faire graphiquement, ça demande des images très spécifiques, le choix des couleurs se complique d’autant, mais le résultat est assez bluffant.

    • Super !

      Au niveau technique (je fais ce que je sais hein :p) il y aurait sûrement moyen de rendre ça générique pour l’activer (avec une config) sur n’importe quel type de contenu (objet SPIP). Le stockage est dans un sous-dossier « article123 » donc on devrait pouvoir avoir la même chose pour « rubrique123 » ou « patate123 ».
      (D’ailleurs je ne vois pas pourquoi l’id est répété dans le nom des fichiers, puisqu’on stocke déjà tout dans un sous-dossier dédié à tel contenu précis.)

      Pour les images, effectivement je ne vois pas ce qu’on pourrait automatiser de plus, et donc il faut forcément des compétences graphiques, c’est sûr.

      À la limite, avec une interface plus complète dans l’admin avec du JS, on pourrait imaginer faire le découpage, définir la ligne où va commencer le dégradé, et créer le dégrader (pas auto, avec un outil graphique pour définir l’amplitude, etc)… il y a des librairies JS qui permettent de manipuler ce genre de choses. Mais bon ça demande un sacré gros boulot en plus…

    • @rastapopoulos :

      – oui sur la généralisation, très juste, juste faire attention que ça stocke trois petites infos en base de donnée de l’objet (intitulé des images, et dimensionnement quand image de fond) ;

      – ne me demande pas pourquoi je répète le numéro dans un dossier déjà numéroté :-))

      – une évolution que j’envisage, effectivement, c’est de ne plus demander deux images pour gérer l’endroit où commence le texte, mais d’utiliser directement un curseur à gérer par glisser-déposer sur l’image dans l’interface privée ; parce que c’est un des points les plus bloquants pour les usagers ;

      – une autre difficulté : mon plugin image_reponsive ne fabrique pas de timestamp, et comme il faut souvent s’y reprendre à plusieurs fois, hé ben c’est pas pratique parce que l’usager lambda se fait planter par son cache quand il veut voir ses nouvelles images…

  • J’ai ajouté un gros paragraphe consacré à « Image adaptative, recadrage et direction artistique » dans ma documentation du #plugin #SPIP image_responsive :
    http://www.paris-beyrouth.org/Plugin-SPIP-Image-responsive

    Ça explique les critères de recadrage que l’on peut utiliser directement dans le filtre image_responsive, comme ceci :

    [(#LOGO_ARTICLE_NORMAL|image_responsive{
            0/480/800/1280/1920/480/800/1280/1920,
            0, 0,
            (max-width: 480px) and (orientation:portrait)/(min-width:481px) and (max-width: 800px) and (orientation:portrait)/(min-width:801px) and (max-width:1280px) and (orientation:portrait)/(min-width:1281px) and (orientation:portrait)/
            (max-width: 480px)/(min-width:481px) and (max-width: 800px)/(min-width:801px) and (max-width:1280px)/,
            4x5/4x5/4x5/4x5/3x2/3x2/3x2/3x2
            })]

    (lequel code fabrique une bonne grosse balise picture en HTML5, extrêmement efficace au niveau de l’affichage, puisque l’image est préchargée, et l’affichage est instantané quand on revient sur une page déjà affichée).

    Pour le plugin lui-même :
    http://zone.spip.org/trac/spip-zone/browser/_plugins_/image_responsive

    • Et je viens d’ajouter un paragraphe sur le précalcul des images avec _IMAGE_RESPONSIVE_CALCULER, ainsi que l’ajout de liens <link> pour faciliter l’aspiration du site, avec _SPIP_LIER_RESSOURCES.

  • Pour le week-end, un #shameless_autopromo : avec @diala on a refait notre site professionnel :
    http://www.paris-beyrouth.org

    Évidemment c’est du #SPIP.

    – La page d’accueil est une de ces #longforms qui sont un peu notre spécialité désormais. Au passage, je rends publique une démonstration que j’ai réalisée il y a quelques années, où j’utilise intensivement mes différentes techniques de « formes longues » :
    http://www.orientpalms.com/demo/spip.php?rubrique2

    – Il y a ces petits SVG animés un peu partout. J’ai d’ailleurs fait une démonstration de ce principe là :
    http://www.orientpalms.com/demo/spip.php?rubrique7

    – Les tutoriaux SPIP sont toujours là, et il faudrait que je trouve le temps d’en rédiger de nouveaux :
    http://www.paris-beyrouth.org/tutoriaux-spip

  • 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…