//(et en le traitant comme s'il était pré-formaté). | //.txt, .text// | //—// | | | //HTMLPlug// | Traite le HTML en remplaçant les liens hypertexte de manière appropriée. Si le document cible d'un lien n'est pas dans la collection, une page intermédiaire est insérée, avertissant l'utilisateur qu'il quitte la collection. Extrait les méta-données déjà disponibles telles que//Title//. | //.htm, .html, .cgi, .php, .asp, .shm, .shtml// | //.gif, .jpeg, .jpg, .png, .css, .rtf// | | | //WordPlug// | Traite les fichiers au format Microsoft Word, en extrayant l'auteur et le titre s'ils sont disponibles, et en laissant les diagrammes et les images aux endroits appropriés. Les outils de conversion utilisés par ce greffon produisent parfois du HTML mal mis en forme, et nous recommandons que vous fournissiez les documents originaux à des fins de visualisation lors de la construction de collections de fichiers Word. Le texte extrait est cependant convenable à des fins de recherche et d'indexation. | //.doc// | //.gif, .jpeg, .jpg, .png, .css, .rtf// | | | //PDFPlug// | Traite les documents PDF, en extrayant la première ligne de texte en tant que titre. Le programme//pdftohtml//ne parvient pas à traiter certains fichiers PDF. Le processus de conversion prend un temps exponentiellement long, et on voit souvent apparaître à l'écran un message traitant de ce processus. Si cela se produit, la seule solution que nous puissions proposer est d'ôter le document concerné de la collection et de recommencer le processus d'import. | //.pdf// | //.gif, .jpeg, .jpg, .png, .css, .rtf// | | | //PSPlug// | Traite les documents PostScript, en extrayant optionnellement les méta-données de date, de titre, et de numéro de page. | //.ps// | //.eps// | | | //EMAILPlug// | Traite les messages de courrier électronique, en reconnaissant l'auteur, le thème, la date, etc. Ce greffon ne traite pas encore correctement les courriers électroniques encodés au format MIME—bien que lisibles, ils ont souvent un aspect étrange. | Doit se terminer par des chiffres ou des chiffres suivis de//.Email// | //—// | | | //BibTexPlug// | Traite les fichiers de bibliographie au format//BibTex//. | //.bib// | //—// | | | //ReferPlug// | Traite les fichiers de bibliographie au format//refer//. | //.bib// | //—// | | | //SRCPlug// | Traite les fichiers de code source | //Makefile, Readme, .c, .cc, .cpp, .h, .hpp, .pl, .pm, .sh// | //.o, .obj, .a, .so, .dll// | | | //ImagePlug// | Traite les fichiers d'images pour créer une bibliothèque d'images. Ne fonctionne que sous Unix. | //.jpeg, .jpg, .gif, .png, .bmp, .xbm, .tif, .tiff// | //—// | | | //SplitPlug// | À l'instar de BasPlug et de ConvertToPlug, il ne faut pas appelé ce greffon directement; il faut plutôt que des greffons qui ont besoin de traiter des fichiers contenant plusieurs documents en héritent. | //—// | //—// | | | //FOXPlug// | Traite les fichiers dbt de FoxBASE | //.dbt, .dbf// | //—// | | | //ZIPPlug// | Décompacte les fichiers//gzip//,//bzip//,//zip//, et//tar//files, pour peu que les outils GNU appropriés soient disponibles. | //.gzip, .bzip, .zip, .tar, .gz, .bz, .tgz, .taz// | //—// | | **Propres à une collection** | //PrePlug// | Traite la sortie HTML en utilisant PRESCRIPT, divisant les documents en pages pour la collection //Computer Science Technical Reports//. | //.html, .html.gz// | //—// | | | //GBPlug// | Traite le texte électronique du projet Gutenberg—qui comprend des informations de titre saisies manuellement. | //.txt.gz, .html, .htm// | //—// | | | //TCCPlug// | Traite les documents de courrier électronique de la collection//Computists' Weekly//(l'hebdomadaire des informaticiens) | Doit commencer par//tcc//ou//cw// | //—// | Les greffons de traitement de documents sont utilisés par le logiciel de construction de collection pour analyser chaque document source d'une manière qui dépend de son format. Le fichier de configuration d'une collection liste tous les greffons utilisés lors de sa construction. Lors de l'opération d'import, chaque fichier ou chaque répertoire est passé tour à tour à tous les greffons jusqu'à ce qu'un greffon soit trouvé qui puisse traiter l'objet -- c'est pourquoi les premiers greffons listés ont la priorité sur des greffons apparaissant plus tard dans la liste. Si aucun greffon ne peut traiter le fichier, un avertissement est affiché (sur la sortie d'erreur standard) et le traitement passe au fichier suivant (c'est pourquoi l'option block_exp peut être utile -- pour éviter ces messages d'erreur dans le cas de fichiers qui sont peut-être présents mais n'ont pas besoin d'être traités). Lors de la construction, on utilise la même procédure, mais c'est le répertoire archives qui est traité en lieu et place du répertoire import. Les greffons standard de Greenstone sont listés table
//TEXTPlug// | //title_sub// | Expression de substitution Perl pour modifier les titres. | | //PSPlug// | //extract_date// | Extrait la date de création de l'en-tête PostScript et la stocke en tant que méta-donnée. | | | //extract_title// | Extrait le titre du document de l'en-tête PostScript et le stocke en tant que méta-donnée de titre. | | | //extract_pages// | Extrait les numéros de pages du document PostScript et les ajoute aux sections appropriées en tant que méta-données sous la balise//Pages//. | | //RecPlug// | //use_metadata_files// | Affecte des méta-données à partir d'un fichier tel que décrit dans la sous-section 2.1.4. | | //ImagePlug// | Diverses options | Voir//ImagePlug.pm.// | | //SRCPlug// | //remove_prefix// | Donne une expression rationnelle de Perl d'un motif à chercher en tête et qu'il faut ôter du nom de fichier. Le comportement par défaut est d'ôter tout le chemin. | ==== Greffons d'import de formats propriétaires ==== Les formats propriétaires posent des problèmes difficiles pour tout système de bibliothèque numérique. Bien qu'ils soient parfois documentés, ils sont susceptibles de changer sans préavis, et il est difficile de suivre le rythme des changements. Greenstone a fait le choix d'utiliser des outils de conversion publiés selon les termes de la GPL (licence publique générale de GNU) par des gens focalisés sur telle ou telle tâche de conversion. Les outils pour convertir les formats Word et PDF sont inclus dans le répertoire packages. Tous convertissent des documents au format texte ou au format HTML. Les greffons HTMLPlug et TEXTPlug prennent ensuite la relève et convertissent ce résultat intermédiaire au format d'archivage de Greenstone. C'est ConvertToPlug qui est utilisé pour inclure les outils de conversion. BasPlug n'est jamais appelé directement, mais les greffons traitant des formats particuliers en héritent, comme illustré figure
]>
1.0/GreenstoneDirectoryMetadata.dtd">
nugget.*
Nugget Point Lighthouse
Nugget Point
nugget-point-1.jpg
Nugget Point Lighthouse , The Catlins
Lighthouse
Le fichier d'exemple contient deux structures de méta-données. Dans chacune, l'élément filename décrit les fichiers auxquels les méta-données s'appliquent, sous la forme d'une expression rationnelle.
//(texte de la section)//
On utilise les marqueurs//%!-- ... --%//car ils dénotent des commentaires en HTML; ces balises de section n'auront donc aucun impact sur la mise en forme du document. On peut spécifier d'autres types de méta-données dans la portion Description, mais ce n'est pas le cas du style de collection décrit ici. On peut aussi imbriquer des balises, de telle sorte que la ligne//(texte de la section)//ci-dessus peut elle-même inclure des sous-sections, telles que
//(texte de la première partie de la section)//
//(texte de la sous-section)//
//(texte de la dernière partie de la section)//
Cette fonctionnalité est héritée par tout greffon utilisant HTMLPlug. En particulier, le greffon Word convertit les données qu'il reçoit au format HTML: on peut donc procéder exactement de la même manière pour spécifier des méta-données dans les fichiers Word (et RTF). Ceci implique un peu de travail en coulisses, puisque lors de la conversion de documents Word vers HTML, le programme prend soin, normalement, de neutraliser les caractères significatifs pour HTML, tels que////; nous nous sommes arrangés pour contourner cette neutralisation dans le cas des spécifications mentionnées ci-dessus. Il faut alors utiliser exactement le même format, même dans des fichiers Word, et ne pas oublier les//%!--//et//--%//qui entourent les méta-données. Le choix des polices et l'espacement n'ont aucune importance.
===== Classificateurs =====
Les classificateurs servent à créer les index de navigation d'une collection, comme par exemple l'index titres A-Z de la collection dlpeople, et les index thème, comment faire, organisation et titres A-Z dans la bibliothèque de développement pour l'humanité, dont la collection «Demo» est un sous-ensemble. La barre de navigation située au sommet des copies d'écran dans les figures 3 et 8a inclut la fonction Rechercher, qui est toujours disponible, suivie par autant de boutons que de classificateurs définis. Les informations servant à la navigation sont stockées dans la base de données d'informations de la collection, et y sont placées par des classificateurs lors de la phase finale du programme buildcol.pl.
1 1 "General reference"
1.2 1.2 "Dictionaries, glossaries, language courses, terminology
2 2 "Sustainable Development, International cooperation, Pro
2.1 2.1 "Development policy and theory, international cooperatio
2.2 2.2 "Development, national planning, national plans"
2.3 2.3 "Project planning and evaluation (incl. project managem
2.4 2.4 "Regional development and planning incl. regional profil
2.5 2.5 "Nongovernmental organisations (NGOs) in general, self-
2.6 2.6 "Organisations, institutions, United Nations (general, d
2.6.1 2.6.1 "United Nations"
2.6.2 2.6.2 "International organisations"
2.6.3 2.6.3 "Regional organisations"
2.6.5 2.6.5 "European Community - European Union"
2.7 2.7 "Sustainable Development, Development models and example
2.8 2.8 "Basic Human Needs"
2.9 2.9 "Hunger and Poverty Alleviation"
L'argument hfile donne le nom d'un fichier, tel que celui de la figure | [Text] |
classify Hierarchy -hfile sub.txt -metadata Subject -sort Title
classify AZList -metadata Title
classify Hierarchy -hfile org.txt -metadata Organisation -sort Title
classify List -metadata Howto
format SearchVList " {If}
{[parent(All':'):Title],[parent(All':'):Title]:}
[link][Title][/link] "
format CL4Vlist "
[link][Howto][/link] "
format DocumentImages true
format DocumentText "[Title]
\\n\\n[Text]"
format DocumentButtons " Expand Text|Expand contents|Detach|Highlight"
La figure ") et contient le texte de Howto, lui-même relié par lien hypertexte au document lui-même. La ligne 1 spécifie la classification Subject (Thème) de la collection «Demo», à laquelle on se référera sous le nom CL1 (puisqu'elle est la première du fichier de configuration), et la ligne 3 spécifie la classification Organisation CL3. Toutes deux sont générées par le classificateur Hierarchy et comprennent donc une structure hiérarchique d'objets VList. La ligne 2 spécifie la dernière classification de la collection «Demo», titres A-Z (CL2). Remarquez qu'il n'existe pas de chaînes de formatage associées aux classificateurs CL1 à CL3. Greenstone dispose de valeurs par défaut pour chaque type de chaîne de formatage; il n'est donc pas nécessaire de positionner une chaîne de formatage quand on ne souhaite pas obtenir un comportement différent du comportement par défaut.
[link][icon][/link]
[link][Title][/link]
Ceci est conçu pour apparaître comme une ligne dans un tableau, ce qui est la manière dont la liste de résultats à une requête est mise en forme. Comme d'habitude, on obtient une petite icone cliquable qui mène au texte, et le titre du document, ancre d'un lien hypertexte qui mène au document à proprement parler.
Dans cette collection, les documents sont hiérarchiques. En fait, l'ancre de lien hypertexte ci-dessus se transforme en le titre de la section renvoyée par le requête. Il serait néanmoins préférable de lui adjoindre également le titre de la section qui la contient, du chapitre qui contient cette dernière, et du livre où ce chapitre apparaît. Il existe un objet de méta-donnée particulier, parent, qui n'est pas stocké dans les documents mais qui est implicite dans tout document hiérarchique, qui produit une telle liste. Elle renvoie soit le document parent ou, si elle est utilisée avec le qualificateur All (tout), la liste de tous les ancêtres au sens hiérarchique, séparés par une chaîne de caractères que l'on peut préciser après le qualificateur All. Ainsi:
[link][icon][/link]
{[parent(All': '):Title]: }[link][Title][/link]
a pour effet de produire une liste contenant le titre du livre, le titre du chapitre, etc., qui entourent la section cible; titres séparés par des caractères deux points, et un dernier caractère deux points est suivi d'un lien hypertexte menant au titre de la section cible.
Malheureusement, dans le cas où la cible est un livre, elle n'aura aucun parent et on verra donc apparaître une chaîne vide suivie d'un caractère deux points. Pour éviter de tels problèmes, on peut utiliser dans une chaîne de formatage des instructions conditionnelles if and or ... else (si et ou ... sinon):
{If}{[metadata], action-if-non-null, action-if-null}
{Or}{action, else another-action, else another-action, etc}
Dans chaque cas les accolades signalent que les instructions doivent être interprétées, et non pas simplement affichées comme du texte. L'instruction If teste si la méta-donnée est vide, et prend la première clause si ce n'est pas le cas, et la deuxième clause si c'est le cas (et si une deuxième clause est fournie). On peut utiliser tout élément de méta-données, y compris la méta-donnée spéciale parent. L'instruction Or évalue chaque action tour à tour jusqu'au moment où elle en rencontre une qui n'est pas vide. Cette action est alors renvoyée en sortie et le reste de la ligne est ignoré.
Si l'on revient à la ligne 5 de la figure
[link][icon][/link]
{If}{[parent(All': '):Title],
[parent(All': '):Title]:}
[link][Title][/link]
Ceci fait précéder la spécification parent d'un test qui examine si le résultat est vide et n'affiche la chaîne du parent que lorsque ce dernier est présent. On peut aussi qualifier parent par Top (sommet) au lieu de All (tout), ce qui donne le nom de document de niveau le plus élevé qui entoure une section -- dans le cas présent, le nom du livre. Nul besoin, avec Top, de chaîne de séparation.
Voici quelques derniers exemples pour illustrer d'autres fonctionnalités. Le classificateur DateList, dans la figure
classify AZSectionList metadata=Creator
format CL2Vlist "[link][icon][/link]
[Creator]
[Title]
[parent(Top):Date] "
La spécification de formatage affiche ces VLists de manière appropriée.
Le mécanisme de chaîne de formatage est souple mais difficile à apprendre. La meilleure manière de procéder est d'étudier des fichiers de configuration de collections existantes.
==== Tirer des liens vers différentes versions d'un document ====
Utiliser le mécanisme//[link] ... [/link]//dans une chaîne de formatage a pour effet d'insérer un lien hypertexte menant au texte du document, en version HTML. Il est utile dans certaines collections de pouvoir afficher d'autres versions du document. Dans une collection de documents au format Microsoft Word, par exemple, il est bon d'être capable d'afficher la version Word de chaque document plutôt que le HTML qui en fut extrait; de même pour des documents PDF.
Pour pouvoir afficher différentes versions d'un document, la clef est d'embarquer les informations nécessaires (c'est-à-dire où se trouvent les autres versions du document) dans le format d'archivage de Greenstone du document. On représente cette information sous la forme de méta-données. Souvenez-vous qu'en plaçant
[link][Title][/link]
dans une chaîne de formatage, on crée un lien vers la version HTML du document, lien dont l'ancre est le titre du document. Les greffons Word et PDF générent tous deux la méta-donnée srclink de telle sorte qu'écrire
[srclink][Title][/srclink]
dans une chaîne de formatage créera un lien vers la version Word ou PDF du document; lien dont l'ancre sera dans cet exemple aussi, le titre du document. Pour permettre d'afficher l'icone appropriée pour les documents Word et PDF, ces greffons générent aussi la méta-donnée srcicon de telle sorte que
[srclink][srcicon][/srclink]
créera un lien étiqueté par l'icone standard pour le format Word ou PDF (selon le cas), et non pas par le titre du document.
===== Contrôler l'interface utilisateur de Greenstone =====
L'interface utilisateur de Greenstone est entièrement contrôlée par des macros placées dans le répertoire GSDLHOME/macros. Elles sont écrites dans un langage conçu spécialement pour Greenstone, et sont utilisées au moment de l'exécution pour engendrer des pages web. La traduction du langage de macros en HTML est la dernière étape de l'affichage d'une page. Ainsi, toute modification à un fichier de macros affecte immédiatement l'affichage, il est donc rapide et facile de faire des expériences avec les macros. Tous les fichiers de macros utilisés par Greenstone sont listés dans le fichier GSDLHOME/etc/main.cfg et sont chargés à chaque démarrage. Signalons l'exception de la version «Bibliothèque locale» sous Windows; dans ce cas il est nécessaire de redémarrer le processus.
Les pages web sont générées à la volée pour de nombreuses raisons, et le système de macros est la manière dont Greenstone implémente la souplesse nécessaire. On peut présenter des pages dans de nombreuses langues différentes, et on utilise un fichier de macros différent pour stocker tout le texte de l'interface dans chaque langue. Quand Greenstone affiche une page l'interpréteur de macros consulte une variable de langue et charge la page dans la langue appropriée (ce système ne va pas, malheureusement, jusqu'à traduire le contenu du document). De même, les valeurs de certaines variables d'affichage, telles que le nombre de documents trouvés par une recherche, ne sont pas connues à l'avance: elles sont interpolées dans le texte de la page à l'aide de macros.
==== Le format des fichiers de macros ====
Les fichiers de macros ont pour extension .dm. Chaque fichier définit un ou plusieurs paquetages, et chaque paquetage définit une série de macros utilisées dans un but précis et unique. À l'instar des classificateurs et des greffons, il existe une base à partir de laquelle construire des macros, appelée base.dm; ce fichier définit le contenu de base d'une page.
Les macros portent des noms qui commencent et finissent par un caractère de soulignement, et leur contenu est défini à l'aide d'accolades. Leur contenu peut consister en du texte brut, du HTML (y compris de liens vers des appliquettes (applets) Java ou du JavaScript), des noms de macros, ou toute combinaison de ces éléments. La macro suivante, extraite du fichier base.dm, définit le contenu d'une page en l'absence de toute macro de remplacement:
_content_ {Oops
_textdefaultcontent_}
Cette page affichera «Oops» à son sommet, suivi du contenu de la macro d'erreur correspondante, _textdefaultcontent_ qui est en anglais définie comme suit: Global:textdefaultcontentThe requested page could not be found. Please use your browsers 'back' button or the above home button to return to the Greenstone Digital Library.; dans d'autres langues, elle affichera une traduction appropriée de cette phrase. En français, on obtiendra par exemple Global:textdefaultcontentLa page demandée n'a pu être trouvée. Utilisez s'il-vous-plaît le bouton «retour» de votre navigateur, ou le bouton «accueil» pour retourner à la Bibliothèque Numérique Greenstone.
Les deux macros _textdefaultcontent_ (contenu textuel par défaut) et _content_ (contenu) se trouvent dans le paquetage global car elles sont requises dans toutes les portions de l'interface utilisateur. Les macros peuvent utiliser des macros d'autres paquetages en tant que contenu, mais il faut alors qu'elles en préfixent les noms par le nom du paquetage. Exemple:
_collectionextra_ {This collection contains _about:numdocs_ documents. It was last built _about:builddate_ days ago.)
provient du fichier french.dm (macros pour le français), et elle est utilisée comme description par défaut d'une collection. Elle fait partie du paquetage intitulé global, mais les macros _numdocs_ et _builddate_ se trouvent toutes deux dans le paquetage about (à propos de...) -- d'où le about qui préfixe leurs noms.
Les macros renferment souvent des conditionnelles, qui ressemblent aux conditonnelles de chaînes de formatage décrites plus haut, à ceci près que leur apparence est un peu différente. Le format de base est _If_(x,y,z), où x est une condition, y est le contenu de macro à utiliser si cette condition est vérifiée, z le contenu à utiliser dans le cas contraire. Les opérateurs de comparaison sont les mêmes que les opérateurs simples utilisés dans Perl (moins que, plus que, égale, différent de). L'exemple suivant, extrait du fichier base.dm, sert à déterminer comment afficher le sommet de la page À propos de cette collection d'une collection:
_imagecollection_ {
_If_( "_iconcollection_ " ne "",
,
_imagecollectionv_)
}
Voilà qui peut sembler abscons. La macro _iconcollection_ vaut la chaîne vide si la collection ne dispose pas d'une icone, ou le nom de l'image dans le cas contraire. Pour paraphraser le code ci-dessus en français: s'il existe une image de collection, afficher l'en-tête de page à propos (à laquelle on se réfère par _httppageabout_) et puis cette image; sinon afficher la solution de secours _imagecollectionv_.
Les macros peuvent prendre des arguments. Voici une autre définition de la macro _imagecollection_, suivant immédiatement la définition donnée plus haut, dans le fichier base.dm:
_imagecollection_[v=1]{_imagecollectionv_}
L'argument [v=1] spécifie qu'il faut utiliser cette deuxième définition quand Greenstone fonctionne en mode texte seul. Les macros de langue fonctionnent de manière similaire -- à l'exception du fichier english.dm, qui est le fichier utilisé par défaut, toutes les macros de langue spécifient leur langue en argument. Par exemple:
_textimagehome_ {Home Page}
apparaît dans le fichier de macros pour la langue anglaise, alors que la version allemande est:
_textimagehome_ [l=de] {Hauptaseite}
Les versions anglaise et allemande se trouvent dans le même paquetage, bien qu'elles soient stockées dans des fichiers séparés (les définitions de paquetages peuvent occuper plusieurs fichiers). Greenstone utilise son argument l au moment de l'exécution pour décider quelle langue afficher.
package about
##############################################
# about page content
###############################################
_pagetitle_ {_collectionname_}
_content_ {
_navigationbar_
_query:queryform_
_iconblankbar_
_textabout_
_textsubcollections_
_help:textsimplehelpheading_
_help:simplehelp_
}
_textabout_ {
_textabcol_
_Global:collectionextra_
}
Comme dernier exemple, la figure