<> Nouvelle Série de placo <> 2004/06/14 <> 2004/10/11

Contexte

terminologie

La dénomination placo vient de planche de contacts.

objectif

Disposer d'une boite à outils adaptée pour créer rapidement et efficacement des présentations de photos au travers de pages html.

stratégie

Après les premières expériences qui finalement n'ont jamais été jusqu'au bout, je révise ma philosophie et au lieu d'avoir des scripts super-compliqués, je tente la stratégie d'une série de scripts plus ou moins simples calqués sur une pratique manuelle. C'est admettre que l'on peut rentrer facilement dans le script pour changer un paramètre d'exécution ou meme ajouter une nouvelle petite fonctionnalité. Mais encore plus :

• que certaines choses doivent pouvoir se faire à la main, à la limite qu'il vaut mieux les faire à la main !
• qu'il est bon de dupliquer les originaux pour augmenter la probabilité de leur conservation.
• qu'il faut accepter une certaine normalisation de l'organisation, en particulier des noms des répertoires, pour réduire le nombre d'arguments des scripts. Si besoin, on modifiera le script pour une utilisation particulière, c'est aussi à cela que Perl est utile !

différentes réalisations modulaires

Pour l'instant, placo peut aider à la mise en oeuvre de trois réalisations indépendantes.

1. la constitution d'une banque d'images normalisées comprenant un certain nombre de fichiers en parallèles. Pour l'instant : les images originales dans ima, les images d'affichage dans pag, les images vignette dans vig, les images de commentaires dans com.
2. l'exploitation de la banque pour faire des mini-ouèbes de présentation.
3. l'exploitation de la banque pour faire des pages illustrées.

vocabulaire

Pour etre précis dans une description, il est capital de préciser les termes utilisés, c'est le pourquoi de cette petite section préalable.

--- à faire ---

Vade-mecum

Voici la suite typique des opérations à réaliser lors de l'utilisation de placo.

1. Mettre en place une banque d'images affichables commentées
   1. créer un répertoire qui contiendra l'ensemble des sous-répertoires standard nécessaires (placo.debute).
   2. repérer le(s) répertoire(s) dans le(s)quel(s) se trouvent les originaux qui vont servir, en préparer les fichiers de sélection (placo.prepare).
   3. compléter les trois fichiers de sélection/description grace à votre éditeur de texte favori.
   4. recopier les images sélectionnées dans le répertoire prévu et préparer les fichiers commentaires (placo.extrait).
   5. travailler les images recopiées (sans leur changer de nom), ne serait-ce que pour retourner les formats verticaux. Dans le meme temps, compléter éventuellement les fichiers de commentaires associés à chaque image (encore avec votre éditeur favori ; le format ne devrait poser aucun problème).
   6. lancer le script de reduction (*.convert) qui avait été préparé au moment de l'extraction et qui confectionne les images réduites pour les vignettes et les affichages dans une page. Ce lancement doit se faire dans le répertoire pro.
2. réaliser une présentation par planche de contacts
   1. préparer un fichier de sélection/hierarchisation des planches de contact (ultérieurement un script réalisera une ébauche standard qu'il suffira de modifer)
   2. lancer enfin placo.construit qui à partir des structures crées réalise les pages html finales.
   3. il est toujours possible de les modifier, mais il ne faut le faire que dans le cadre d'une présentation finalisée du point de vue de la construction automatique.
3. réaliser les illustrations d'un texte par des images (en cours de confection).

Organisation contrainte

Evidemment en standardisant l'organisation, on perd un peu de liberté mais on gagne en automatisation et simplicité.

les répertoires

Tous les fichiers d'un ensemble sont répartis dans un certain nombre de répertoires de nom obligatoires qui se trouve dans un meme répertoire dit central que choisit l'utilisateur. A sa racine ne se trouvent normalement que les fichiers d'accueil index.html et welcome.html qui sont générés par placo (encore à faire) et qui permettent d'accèder à toutes les présentations utilisant la banque d'images.

Il est pertinent de classer ces répértoires en trois catégories

répertoires gérés par placo

Gérés par placo dans le sens, où ce ne sont normalement que les scripts qui interviennent pour créer ou lire des fichiers dans ces répertoires.

• vig : contient les images vignettes associées aux images de la banque d'images.
• pag : contient les images dans le format d'affichage pour pages html de la banque d'images.
• iht : contient les fichiers html associés à certaines des images des fichiers pag et vig, il peut y avoir plusieurs fichiers pour la meme image puisque plus d'une présentation peut s'en servir. La caractéristique de ces fichiers est de ne présenter qu'une image.
• htm : contient les pages html considérées d'accueil qui sont référencées dans les fichiers d'accueil général à la racine. La caractérisque de ces fichiers est de présenter des vignettes.
• pla : (non encore implanté) pour stocker des informations de souvenir utilisables d'un script de placo à l'autre.

répertoires gérés par placo et l'utilisateur

Ces répertoires sont dit gérés par placo et l'utilisateur car en général, les fichiers bruts sont générés par placo, et améliorés, complétés par l'utilisateur (retouche pour les images, informations supplémentaires pour les commentaires).

• ima : contient les images originales qui servent à alimenter vig et pag. Mais peut contenir aussi des images intermédiaires de travail. Pour des exportations propres, il est nécessaire que les images destinées aux deux répertoires d'affichages conservent le nom attributé lors de la création.
• com : contient les commentaires associées aux images à utiliser de ima. Mais il n'est pas obligatoire d'en mettre un pour chaque image de la banque (à vérifier si cela marche).
• pro : contient les fichiers propres aux arguments des différentes applications de placo. Là aussi certains sont initiés par des applications placo, puis modifiés par l'utilisateur. Il est aussi conseiller d'y mettre aussi ses scripts de lancement.

répertoires gérés par l'utilisateur

Ces répertoires ne sont pas utiles à placo mais il apparait judicieux de les suggérer à l'utilisateur. Si celui-ci le désire, il peut bien entendu en créer d'autres mais il ne seront pas pris en compte par les procédures placo de sauvegarde et recopie...

• ori : dans lequel l'utilisateur peut placer ses images originales, dont éventuellement certaines ne sont utilisées dans aucune applications ; ce qui ne veut pas dire non plus que toutes celles qui sont utilisées en proviennent... C'est un espace de stockage pour lui, normalement d'images originales.
• div : un répertoire pour mettre tout ce qui ne peut pas etre mis dans les autres, par exemple des fichiers où sont notées des idées...

tableau synoptique

--- à faire ---

Il s'agit d'un tableau dont les lignes sont les différents répertoires et les colonnes différentes caractériques, du genre :

• qui les crée
• qui les modifie
• qui les lit
• information contenue
• ...

remarques supplémentaires

Normalement, il y a correspondance stricte entre les séries des fichiers des trois répertoires : vig, pag et com. Les images correspondantes devraient se trouver dans ima (au moins au moment de l'utilisation de placo.extrait. Les fichiers contenus dans iht (presentation.nom.###.html) peuvent référer la meme image dans plusieurs présentations et ne pas appeler toutes les images.

la dénomination des fichiers

Là aussi, on peut classer les fichiers en quelques catégories assez tranchées :

les fichiers images

• les fichers image (qui ne sont pas forcément des images, mais associés à une image ont un nom basé sur la structure suivante.

  contexte.nom.code.ext

  • contexte peut ne pas etre présent, il permet de distinguer les différents types d'affichage qui utilisent les memes images.
  • nom est un nom libre de l'utilisateur, il correspond au mot clef principal si on passe par placo pour générer les images originales.
  • code est un code numérique de TROIS chiffres (qui permet donc 1000 possibilités, mais en général 000 n'est pas utilisé) qui permet de distinguer les images de meme nom.
  • ext est une extension indiquant le format du fichier. Pour l'instant jpg, mais cela peut changer ; html pour les pages html...

  Normalement, tous les caractères sont/doivent être en minuscules, les blancs et plus généralement les caractères spéciaux sont proscrits de toutes ces composantes.

• Rappel : la même image, par exemple sous différentes tailles se nomme de manière identique, c'est le répertoire qui permet de faire la distinction.

les fichiers arguments

Leur format est de deux composantes :

contexte.type

En général, le contexte est lié à la présentation concernée. Parmi les types on peut relever :

• sed : annotation par la date,
• sel : annotation par le lieu,
• ses : annotation par des commentaires (titre, mots clef, commentaires sur plusieurs lignes).
• shi : définit une hiérarchie (pour l'instant à deux niveaux) de présentation des images dans une présentation planches de contacts.

Détails utiles sur l'annotation

introduction

L'annotation se fait en 2 temps :

1. Préparer des fichiers qui seront exploités par placo.extrait, il s'agit en fait de compléter par des infos des fichiers préparés par placo.prepare. Cette opération est quasiment indispensable car la plupart des placo traitant des images ont besoin des trois répertoires remplis en parallèle.
2. Compléter les fichiers produit et placés dans le répertoire com selon l'inspiration poétique que les images peuvent créer. Cette seconde annotation n'est pas obligatoire.

Première opération

Trois fichiers sont donc en cause : (1) pour les dates, (2) pour les lieux, (3) pour les séries & titres & commentaires. Les trois fichiers ont même première composante et des extensions obligatoires, respectivement : sed, sel et ses.

Le premier ( annotation.sed) est le plus simple, il indique la date de la prise de photo. En fait dans le cas de la dénomination des fichiers par Camedia placo.extrait a déjà fait tout le travail, mais on peut corriger la donne. Il n'est pas nécessaire de dater toutes les photos, le même principe que décrit juste après pour les lieux s'applique.

Le second ( annotation.sel) est aussi assez simple, il indique le lieu de la prise de photo. Le principe est basé sur le fait que les photos sont triées, et qu'il suffit d'indiquer le lieu pour la première photo de changement de lieu.

Le troisième ( annotation.ses) est le plus riche et le plus long à constituer, c'est le seul qui soit indispensable. Il indique :

1. Si la photo va etre sélectionnée (ne le sont que celles qui sont contenues dans le fichier).
2. La série à laquelle va appartenir la photo, sorte de mot-clef rustique principal. (obligatoire car c'est lui qui déterminera la première composante du nom dans la photo ; mieux vaut ne pas y placer des caractères spéciaux).
3. Une petite collection de mots-clef additionnels (facultatif). Comme le mot-clef de la série, ils ne doivent pas contenir d'espaces (puisque c'est l'espace qui est séparateur).
4. Le titre (on suggère court) qui sera associé à la photo. (facultatif).
5. Le commentaire plus long associé à la photo. (facultatif, mais on ne peut pas placer de commentaires s'il n'y a pas de titre : il serait pris comme titre).

Le format est assez simple :

• une ligne par photo sélectionnée,
• le premier mot est le nom de l'image dans le fichier d'extraction,
• le suivant est le mot clef de la série,
• évenutuellement séparés par des espaces " " d'autres mots clef supplémentaires,
• éventuellement séparé par des slash "/" un titre,
• enfin un commentaire qui peut se mettre en plusieurs paragraphes indiqués aussi par des slash "/". D'une certaine manière, on peut dire que le titre est le premier paragraphe.

Remarque : on fera attention que pour l'instant, il n'est pas prévu d'échappement pour le slasch séparateur et que donc il n'est pas possible (pour l'instant) de l'introduire en tant que tel !

On aura sans doute noté la possibilité d'introduire des lignes de commentaires ignorées par les programmes, en apposant en première position un "#". Ceci est valable pour les trois fichiers.

Cette première annotation se conclut par le lancement de placo.extrait qui place dans le répertoire com les fichiers nom.###.txt pour chaque image.

Remarque : la distinction entre les dates, les lieux et les mots clefs additionnel sera fictive dans l'utilisation. Seule le premier clef joue vraiment un rôle différents.

seconde opération

A tout moment, il est possible de reprendre les fichiers contenant les annotations et les modifier/compléter en respectant le format adopté qui est assez simple et parlant de lui même.

différents scripts actuels

Des liens sont placés sur les différents titres pour une consultation aisée du code.

placo.pm

Ce n'est pas un script au sens strict, puisque c'est le module qui contient les constantes et fonctions générales aux différents scripts.

placo.debute

Ce script crée une arborescence avec tous les répertoires vides suivant la normalisation des noms adoptés. Il n'a besoin que d'un argument le nom du répertoire central qui les contiendra et qui ne doit pas préexister. Il y place les répertoires normalisés. Un second argument peut donner le chemin où placer le premier répertoire, sinon par défaut il sera placé dans le répertoire courant. Bien entendu, ces répertoires sont complètement vides.

placo.inspecte

Ce script explore les différents répertoires et rend compte du bilan de son investigation. En particulier, il vérifie la bonne correspondance des fichiers images des répertoires associés de la banque d'image : ima - vig - pag - iht.

Si la cohérence n'est pas bonne, il sort les fichiers qui différent (l'algorithme serait certainement à améliorer... sans doute assez facile en pratiquant un tri astucieux : plus tard, et toutes les comparaisons ne sont pas en place et/ou à jour avec les nouvelles normes : à reprendre).

placo.prepare

La préparation est celle de la définition d'une extraction à partir d'un répertoire extérieur pour éviter d'avoir à retaper à la main le nom des fichiers images extérieures. Plus précisément, en explorant un répertoire donné placo.prepare place dans un autre répertoire donné, trois fichiers contenant la liste alphabétique des fichiers images qu'il a identifié dans le premiere répertoire. Ce sont bien sur les fichiers qui vont guider l'annotation et que l'on suffixe par (sed, sel et ses). C'est un peu un dir ou un ls spécialisé. Les noms sont mis par ordre alphabétique, ce qui permet d'utiliser simplement les visualisateurs (comme Kuickshow) pour pratiquer l'annotation sans avoir à retaper les noms des fichiers initiaux. Pour plus de détails voir la section décrivant le processus d'annotation.

placo.extrait

A partir du (ou des) fichiers *.se? résultant du processus d'annotation, placo.extrait réalise l'extraction en copiant des fichiers dans les répertoires ima et com. Remarque importante: c'est lui qui pose les codes (3 valeurs numériques du nom des fichiers) en tenant compte des fichiers déjà présent de manière à ne pas réécraser en cas de lancement répété d'icelui ; cependant, c'est la porte ouverte aux répétitions. Il prépare dans le même temps le fichier script *.convert de conversion par image_magick::convert qui sera à lancer une fois que les modifications manuelles (retailler, retravailler... et surtout retourner pour les images verticales) sur les images contenues dans ima seront réalisées. A ce moment, on doit avoir des collections de fichiers cohérentes que placo.inspecte peut vérifier.

placo.construit

Ce script crée les pages *.html nécessaires en fonction d'instruction définies dans le fichier *.shi dans les répertoires htm et iht. Il faudra l'enrichir pour permettre des jonctions entre différents mini-ouèbes et surtout des présentations plus personnalisées que les tableaux de vignettes.

Dans la version actuelle, il ne fait la hiérarchie des tables de présentation que sur les mots clefs principaux... Il faudra trouver des commodités pour employer aussi les autres mots clefs (cf. Idées à garder en fin de cette note).

Principe actuel : les instructions se trouvent dans le fichier d'extension shi, en voici un exemple : exemple.shi. Chaque ligne correspond à une table de vignette finale. Le premier mot donne le nom des images à rassembler (dans une table finale, toutes les images sont donc de même nom), les autres donnent les codes des images dans l'ordre où elles seront disposées par ligne. La première image servira aussi dans la table de vignettes de premier niveau qui permet d'accèder aux tables de niveau final. Il serait bon de permettre à ce que cette image ne soit pas obligatoirement présente dans la table finale, puisqu'elle représente plus un titre qu'autre chose.

placo.texte

Ce script reprend simplement un texte en html dans lequel il introduit des vignettes avec lien sur les images correspondantes aux endroits indiqués par un codage simple. Ce codage est simplement l'emploi d'un triple parenthésage comme (((nam.123))). La vignette est placée dans le texte sans autre précaution.

ATTENTION : pour l'instant, placo.texte est très sensible. Si vous mettez une 4ème parenthèse collée parce qu'elle correspond à votre texte, cela semble le faire tourner en boucle...

Tout dépend des gouts, mais l'insertion de vignettes en plein milieu du texte produit un interlignage très gros, irrégulier et disgracieux... Il est plus agréable de mettre les vignettes dans une colonne de droite ou de gauche ; chaque ligne du tableau correspond à un paragraphe du texte. Mais, il faut le plus souvent régler à la main la largeur de la colonne contenant les vignettes, ce qui n'est pas immédiat (car dépend du nombre de vignette par paragraphe). On peut aussi utiliser alternativement la 1ère ou la 2ème colonne pour les vignettes... En fait le mieux est d'alterner paragraphes de texte et paragraphes de vignettes séparées par un espace.

A garder pour la suite

• la version d'ImageMagick me permet de récupérer dates et info techniques de mes images par le programme identify. En voici, une bonne nouvelle. Ce pourrait etre utile pour stocker les dimensions de l'image qui seraient bien utiles au moment de la construction des pages html. Par exemple pour diminuer la taille des vignettes.
• il faudrait qu'une exportation d'un miniouèbe comporte aussi une page de présentation de l'utilisation de placo avec un bouton d'aide qui serait mis dans les pages d'accueil.
• faire des subroutines générales d'écriture et de lecture des champs des fichiers commentaires du répertoire com.
• faire l'équivalent de placo.prepare pour proposer un fichier *.shi à améliorer à l'utilisateur.
• faire un placo qui repère toutes les pages d'accueil à la racine et qui fait deux pages index et welcome l'une liée à l'autre pour le renvoi
• donner aussi à placo.inspecte une fonctionnalité de sauvegarde, de recopie à différents niveaux...
• faire un bilan par une page ouèbe du contenu d'une banque de données (index, différents liens sur une table réca complète).
• faire en sorte que extrait n'ait plus besoin d'un espace devant "/" (je ne comprends plus ce que cela veut dire) !
• debute n'a pas l'air de marcher sous dos !
• permettre d'autres mini-ouèbes à partir d'une banque de données que celui formé par le 1er mot-clef qui sert à dénommer les fichiers. On pense à :
  • un affichage par date,
  • un affichage par lieu,
  • un affichage par les autres mots-clefs.

  Pour obtenir de tels possibilités à partir de l'organisation actuelle, il me semble que les dispositions suivantes devraient suffirre :

  • généraliser placo.construit pour qu'il prenne comme fichier *.shi des définitions basées sur les noms complets des fichiers et non pas supposer une recomposition implicicte avec les noms et codes,
  • que placo.extrait au moment où il détermine la dénomination des fichiers de la banque crée (par exemple dans un répertoire nouveau pla pour les fichiers de gestion de placo) un fichier notant pour chaque fichier les info nécessaires, à savoir la date, le lieu et les mots clef qui pourraient etre réexploités par la suite.

    Cette proposition présente l'inconvénient d'impliquer des contradictions entre cette table nouvelle et les fichiers de commentaires créés par l'utilisateur... Faut-il proposer des mises à jour automatiques, respectant les autres champs modifiés évenuellement par l'usager ? A réfléchir !

• Attention, il m'a semblé que placo.texte a eu des difficultés si le nombre de parenthèses n'est pas correct...
• Imaginer une taille de mini-vignette pour l'insertion dans les texte car la dimension pour les planches de contact est trop importante ???
• Je me demande si c'est très prudent de laisser placo mettre des choses dans pro, si on ne risque pas par maladresse d'écraser beaucoup de travail ? A réfléchir...
• Ce serait bien d'avoir un bilan des fichiers pour détecter les erreurs du genre "portrait" tapé comme "portait" !
• A terme, je me demande si ce ne serait pas une meilleure idée que de permettre les noms des fichiers d'etre n'importe quoi ? Ce qui n'empecherait pas d'utiliser les mots clefs principaux ou secondaires, au contraire.
• Réfléchir à l'utilisation du passage de la souris sur une image pour la modifier (éclaircissement...).