La méthode
- On part depuis une image source que l’on nommera image_originale.ext par la suite
- Chaque modification de l’image par l’ajout d’un filtre ou une modification de la taille depuis l’interface créera une image dénommée image_originale-modimage-X.ext ou X s’incrémentera en fonction de la succession des effets
- Ainsi on garde une sorte d’historique des images qui pourront être comme ceci :
- image_originale.ext
- image_originale-modimage-1.ext
- image_originale-modimage-2.ext
- image_originale-modimage-3.ext
- image_originale-modimage-4.ext
- (...)
- Ces références à des documents intermédiaires sont mis de coté dans une table intermédiaire que l’on nommera "spip_documents_inters", ainsi rien n’est perdu dans l’immédiat et on peut afficher ces étapes intermédiaires pour y revenir par la suite.
- Afin de ne pas encombrer inutilement le disque du serveur avec des images qui ne servent à rien (étapes de l’appllication de plusieurs filtres), les images intermédiaires seront néttoyées par cron à intervalle fixé dans l’interface de configuration (CFG). Les étapes intermédiaires deviendront alors inaccessibles puisque supprimées.
- Ainsi, à la fin de tout cela, il ne nous restera que 2 images, image_originale.ext (qui est l’image originale qui ne bougera jamais) et image_originale-modimage-X.ext ou X représente le dernier numéro de version.
NB : à tout moment, il doit être possible de revenir à l’image originale à l’aide d’un bouton dans le panel de modification.
La table spip_documents_inter
- "id_documents_inter" => "bigint(21) NOT NULL AUTO_INCREMENT",
- "id_document" => "bigint(21) NOT NULL", //document original
- "id_auteur" => "bigint(21) NOT NULL", //qui a modifié
- "extension" => "VARCHAR(10) DEFAULT '' NOT NULL",
- "fichier" => "varchar(255) DEFAULT '' NOT NULL",
- "taille" => "integer",
- "largeur" => "integer",
- "hauteur" => "integer",
- "mode" => "ENUM('vignette', 'image', 'document') DEFAULT 'document' NOT NULL",
- "version" => "bigint(21) NOT NULL",
- "maj" => "TIMESTAMP", //quand ca a eut lieu
- );
- "PRIMARY KEY" => "id_documents_inter, id_document",
- "KEY id_document" => "id_document",
- "KEY id_auteur" => "id_auteur");
- global $tables_principales;
- 'field' => &$documents_inters,
- 'key' => &$documents_inters_key);
- global $tables_jointures;
- $tables_jointures['spip_documents_inters'][] = 'documents';
- $tables_jointures['spip_documents_inters'][] = 'documents_articles';
- $tables_jointures['spip_documents_inters'][] = 'auteurs';
- global $table_des_tables;
- $table_des_tables['documents_inters']='documents_inters';
Les modifications possibles
Tout d’abord on se base sur les possibilités par défaut de spip fait le tour de tout ce qui peut nous intéresser :
Pour les actions :
L’action TOURNER, déjà présente dans l’admin de spip (à modifier certainement pour la gestion de nos versions)
Pour les filtres :
Tous les filtres d’images de base de spip à savoir :
- image_alpha
- image_flip_horizontal
- image_flip_vertical
- image_flou
- image_gamma
- image_nb
- image_recadre
- image_rotation
- image_sepia
Les filtres supplémentaires du plugins fonctions images :
- image_sincity
- image_saturer (http://www.paris-beyrouth.org/De-sa...)
- image_podpod (http://www.paris-beyrouth.org/Creer...)
Les contraintes
- D’après Arno* (et il a fortement raison), le format Jpeg est fortement destructeur et l’application de modifications successives sur un fichier de ce format engendrerait une perte de qualité importante à chaque fois. Sa solution (dans le même article) consisterait à passer par une étape intermédiaire en transformant l’image en PNG 24 (Portable Network Graphics) qui, lui, n’est pas destructeur. À la création de la première version l’équivalent du filtre "
|image_alpha{0}" est donc appliqué automatiquement. - Ce plugin nécessite :
- Spip 1.9.3 svn révision 11315 (Je n’ai pas testé en dessous)
- Le plugin cfg développé par toggg et marcimat
- jQuery (1.2.3)
- Le plugin UI
- Le plugin farbtastic pour jQuery
- Le plugin imgAreaSelect pour jQuery
