http://fr.orientpalms.com

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) :

http://orientxxi.info/IMG/arton1423.jpg

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

http://i.imgur.com/WGJaQxN.jpg

(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 :

http://i.imgur.com/VaAKSIY.jpg

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

http://orientxxi.info/IMG/fonds/article1423/img_haut1423.jpg http://orientxxi.info/IMG/fonds/article1423/fond_haut1423.jpg

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 :

http://i.imgur.com/JHXowVn.jpg

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.

http://i.imgur.com/PUS7ayG.jpg

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

http://i.imgur.com/fvNXCLn.jpg

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 :

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 :

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 :

http://i.imgur.com/IMLOOPi.jpg

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…

#spip_blog

▻https://mastodon.social/@0gust1/2351932

Ça bouge plus du côté de Mastodon :D

Je n’irais pas faire du subsetting précis pour chaque langue, sinon tu vas retomber dans les problèmes historiques des multiples variantes régionales d’ISO 8859 : multilinguisme problématique (tu veux écrire « as the French say : “qui vole un œurf vole un bœuf” » dans un article du site anglais, et hop, le « œ » est tout pété – private joke), noms étrangers qui utilisent des caractères qui ne sont pas dans ton subset (tu parles de « Håkan Juholt » dans un article en français, et le « å » apparaît tout moche parce que tu ne l’as pas conservé dans le subset de la fonte du site français), et à l’heure d’Unicode l’habitude des gens de détourner les caractères d’une autre langue pour faire des effets de signature graphique…

Sur Orient Palms, il se trouve justement que j’ai 15 langues différentes, et que j’utilise un certain nombre de fontes différentes, justement pour éviter d’avoir une énorme police Unicode « complète » à charger… Mais j’ai vraiment limité les variantes :
– il y a la police avec les caractères latins (tous ceux dessinés par le typographe, ça me couvre de l’espagnol à l’allemand en passant par le français et le suédois… Comprendre que j’ai ici une seule version de la police de caractère pour 9 langues différentes :
▻http://www.orientpalms.com
▻http://fr.orientpalms.com
▻http://tr.orientpalms.com
▻http://pt.orientpalms.com
▻http://es.orientpalms.com
▻http://de.orientpalms.com
▻http://it.orientpalms.com
▻http://sv.orientpalms.com
▻http://nl.orientpalms.com

– il y a le fichier du même dessin de caractère avec les caractères cyrilliques et latins (grosso modo deux fois plus lourde),
▻http://ru.orientpalms.com

– il y a encore un fichier du même dessin de caractère, mais avec les dessins grecs et latins (donc égalemment plus lourde que le latin seul),
▻http://el.orientpalms.com
(uniquement sur les sous-titres, les gros titres restent en caractères latins ici)

– il y a un fichier pour les caractères arabes (la fonte contient les caractères latins les plus courants),
▻http://ar.orientpalms.com

– et pour le fun, dans la version coréenne j’ai une (énorme - 1Mo) fonte dédiée, tellement grosse que soit c’est une idiotie soit je compte sur le fait que les coréens ont la meilleure connexion du monde…
▻http://ko.orientpalms.com

– je n’utilise pas de webfonts pour le chinois, ni pour le japonais, parce que là aussi, ça ferait des polices énormes (et on a un traffic pas négligeable sur la Chine, alors je soigne un peu plus l’expérience utilisateur sur cette version).

Par ailleurs, comme je l’ai déjà documenté ici, je n’utilise plus que WOFF et WOFF2, qui sont bien compactés.

Un des aspects à prendre en compte :
– pas question pour moi de gérer 15 fichiers de police différents, c’est le meilleur moyen de se planter dans son organisation et ses mises à jour (surtout si tu t’amuses à modifier des dessins de caractères, je te dis pas s’il faut le reproduire ensuite dans 15 fontes différentes…) ; et comme généralement on a besoin de plusieurs fontes pour faire quelque chose de joli, on multiplie encore le nombre de fichiers (sur Orient Palms, j’ai 2 webfontes dans ma maquette) ;
– je préfère éviter le recours aux options CSS de range Unicode pour gérer par exemple Grec et Latin avec deux fichiers de polices différents qui se complèteraient : d’abord parce qu’il faudrait encore tester la compatibilité du truc (avec les Webfonts et Unicode, je me méfie très lourdement des implémentations dans les brouteurs, qui ont toujours été historiquement merdiques) ; surtout parce que je préfère charger un fichier plutôt que deux.

Après, perso, je préfère généralement n’utiliser que des polices de titraille, j’évite les webfonts sur le texte courant (problèmes de rendus et de lisibilité, temps de chargement des polices sur du texte qu’on devrait pouvoir lire immédiatement, et besoin de 3 voire 4 fichiers juste pour assurer l’affichage gras/italique…). Ça limite énormément les problèmes de subsetting par langue, parce que les caractères hors-subset et le multilinguisme, c’est beaucoup plus rare (genre mettre une citation originale en cyrillique dans un article en anglais, ça se fait, mais dans le titre c’est beaucoup plus rare).

Sinon, si tu tiens à tester pour chaque langue, il y a une astuce que j’avais faite pour ajouter des langues à mon #plugin #SPIP de détection de langues : j’avais besoin de connaître la fréquence des séries de 3 lettres dans quelques langues manquantes dans le script d’origine.

Du coup je suis allé sur le projet Gutenberg, j’ai récupéré quelques gros romans dans la langue qui me manquait, j’ai collé tous les textes (bruts) dans un fichier, et hop j’ai fait une moulinette qui a compté les séries de 3 lettres et m’a retourné un tableau de leurs fréquences respectives. Tu peux facilement faire la même chose pour connaître la fréquence des caractères utilisés dans une langue… (mais voir mon message précédent, je ne pense pas que ce soit une bonne idée).

Roh, merci pour tout ces détails, ça donne à réfléchir. Je savais bien que sur seenthis j’allais avoir de la matière :)

Le contexte chez mon client est légèrement différent : sites e-commerce assez ciblés (contenus peu ou pas littéraire), et grosse préoccupation webperf. Il est très improbable que l’on ait à utiliser des caractères sortant du subset.

Comme tu le soulignes, l’enjeu lors du subsetting, est de décider ce qu’on inclue ou non...

Pour l’instant, j’ai un générateur « toutautomatisé » (utilisant ▻https://github.com/ecomfe/fontmin), qui prend en entrée un ensemble de fichiers ttf (la Roboto et toutes ses variantes, dans mon cas) et une liste de fichiers texte UTF8 (1 par pays), contenant les caractères à utiliser (en faisant gaffe aux caractères invisibles).

Il produit en sortie les formats attendus (woff2, woff, etc...) rangés dans des répertoires qui vont bien. Bien sûr, l’approche ne vaut que pour les sites « européens » (pour simplifier), je ne me suis pas attaqué encore au site chinois.

L’avantage d’avoir tout automatisé, est qu’on pourra changer rapidement le subsetting sans que ce soit la plaie.
Je croise les doigts, et j’espère bien que ma solution tiendra la route.

Au départ, j’ai cherché à comprendre comment faisait ▻https://fonts.google.com pour proposer des webfonts aussi légères. Grosso modo, en plus des optimisations classiques ils génèrent plus de 30 variantes par fonte, optimisées sur mesure et servies dynamiquement selon l’OS et le User-agent. Cet aspect n’est bien sûr pas documenté, et je n’ai pas le temps, les compétences ni le courage de faire la rétro-ingénierie.

Et à l’instant, sortie du deuxième extrait de son album : Li fi Halab (Ce qu’Alep conserve pour moi)
▻https://www.youtube.com/watch?v=6iJIqSwc7uI

Et je viens de faire la traduction en français :
▻http://fr.orientpalms.com/La-musique-dans-le-Mur