legacy:manuals:en:develop:getting_the_most_out_of_your_documents
no way to compare when less than two revisions
Differences
This shows you the differences between two versions of the page.
— | legacy:manuals:en:develop:getting_the_most_out_of_your_documents [2023/03/13 01:46] (current) – created - external edit 127.0.0.1 | ||
---|---|---|---|
Line 1: | Line 1: | ||
+ | |||
+ | |||
+ | |||
+ | ====== Getting the most out of your documents ====== | ||
+ | |||
+ | Collections can be individualised to make the information they contain accessible in different ways. This chapter describes how Greenstone extracts information from documents and presents it to the user: the document processing (Section [[# | ||
+ | |||
+ | ===== Plugins ===== | ||
+ | |||
+ | Plugins parse the imported documents and extract metadata from them. For example, the html plugin converts html pages to the Greenstone archive format and extracts metadata which is explicit in the document format—such as titles, enclosed by //< | ||
+ | |||
+ | Plugins are written in the Perl language. They all derive from a basic plugin called // | ||
+ | |||
+ | To find more about any plugin, just type // | ||
+ | |||
+ | You can easily write new plugins that process document formats not handled by existing plugins, format documents in some special way, or extract a new kind of metadata. | ||
+ | |||
+ | ==== General Options ==== | ||
+ | |||
+ | Table <tblref table_options_applicable_to_all_plugins> | ||
+ | |||
+ | < | ||
+ | |< - 132 397 >| | ||
+ | | ''< | ||
+ | | ''< | ||
+ | | ''< | ||
+ | | ''< | ||
+ | | ''< | ||
+ | | ''< | ||
+ | | ''< | ||
+ | | ''< | ||
+ | | ''< | ||
+ | | ''< | ||
+ | | ''< | ||
+ | | ''< | ||
+ | |||
+ | ==== Document processing plugins ==== | ||
+ | |||
+ | < | ||
+ | |< - 60 72 236 85 76 >| | ||
+ | | | | **Purpose** | **File types** | **Ignores files** | | ||
+ | | **General** | //ArcPlug// | Processes files named in the file // | ||
+ | | | //RecPlug// | Recurses through a directory structure by checking to see whether a filename is a directory and if so, inserting all files in the directory into the plugin pipeline. Assigns metadata if // | ||
+ | | | //GAPlug// | Processes Greenstone archive files generated by // | ||
+ | | | TEXTPlug | Processes plain text by placing it between //< | ||
+ | | | // | ||
+ | | | // | ||
+ | | | //PDFPlug// | Processes PDF documents, extracting the first line of text as a title. The // | ||
+ | | | //PSPlug// | Processes PostScript documents, optionally extracting date, title and page number metadata. | //.ps// | //.eps// | | ||
+ | | | // | ||
+ | | | // | ||
+ | | | // | ||
+ | | | //SRCPlug// | Processes source code files | //Makefile, Readme, .c, .cc, .cpp, .h, .hpp, .pl, .pm, .sh// | //.o, .obj, .a, .so, .dll// | | ||
+ | | | // | ||
+ | | | // | ||
+ | | | //FOXPlug// | Processes FoxBASE dbt files | //.dbt, .dbf// | //—// | | ||
+ | | | //ZIPPlug// | Uncompresses //gzip//, //bzip//, //zip//, and //tar// files, provided the appropriate Gnu tools are available. | //.gzip, .bzip, .zip, .tar, .gz, .bz, .tgz, .taz// | //—// | | ||
+ | | **Collection < | ||
+ | | | //GBPlug// | Processes Project Gutenberg etext—which includes manually-entered title information. | //.txt.gz, .html, .htm// | //—// | | ||
+ | | | //TCCPlug// | Processes E-mail documents from Computists' | ||
+ | |||
+ | Document processing plugins are used by the collection-building software to parse each source document in a way that depends on its format. A collection' | ||
+ | |||
+ | The standard Greenstone plugins are listed in Table <tblref table_greenstone_plugins> | ||
+ | |||
+ | Some plugins are written for specific collections that have a document format not found elsewhere, like the E-text used in the Gutenberg collection. These collection-specific plugins are found in the collection' | ||
+ | |||
+ | Some document-processing plugins use external programs that parse specific proprietary formats—for example, Microsoft Word—into either plain text or html. A general plugin called // | ||
+ | |||
+ | Some plugins have individual options, which control what they do in finer detail than the general options allow. Table <tblref table_plugin-specific_options> | ||
+ | |||
+ | < | ||
+ | |< - 132 132 265 >| | ||
+ | | | **Option** | **Purpose** | | ||
+ | | // | ||
+ | | | // | ||
+ | | | // | ||
+ | | | // | ||
+ | | | // | ||
+ | | | // | ||
+ | | | // | ||
+ | | | // | ||
+ | | | // | ||
+ | | // | ||
+ | | //PSPlug// | // | ||
+ | | | // | ||
+ | | | // | ||
+ | | //RecPlug// | // | ||
+ | | // | ||
+ | | //SRCPlug// | // | ||
+ | |||
+ | ==== Plugins to import proprietary formats ==== | ||
+ | |||
+ | Proprietary formats pose difficult problems for any digital library system. Although documentation may be available about how they work, they are subject to change without notice, and it is difficult to keep up with changes. Greenstone has adopted the policy of using GPL (Gnu Public License) conversion utilities written by people dedicated to the task. Utilities to convert Word and PDF formats are included in the // | ||
+ | |||
+ | < | ||
+ | {{..: | ||
+ | |||
+ | When // | ||
+ | |||
+ | Sometimes there are several conversion utilities for a particular format, and // | ||
+ | |||
+ | The steps involved in adding a new external document conversion utility are: | ||
+ | |||
+ | - Install the new conversion utility so that it is accessible by Greenstone (put it in the // | ||
+ | - Alter // | ||
+ | - Write a top-level plugin that inherits from // | ||
+ | |||
+ | ==== Assigning metadata from a file ==== | ||
+ | |||
+ | The standard plugin //RecPlug// also incorporates a way of assigning metadata to documents from manually (or automatically) created XML files. We describe this in some detail, so that you can create metadata files in the appropriate format. If the // | ||
+ | |||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | ]> | ||
+ | </ | ||
+ | |||
+ | |||
+ | |||
+ | < | ||
+ | < | ||
+ | <?xml version=" | ||
+ | < | ||
+ | " | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | </ | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | |||
+ | |||
+ | The example file contains two metadata structures. In each one, the // | ||
+ | |||
+ | Metadata elements are processed in the order in which they appear. The second structure above sets //Title// metadata for the file named // | ||
+ | |||
+ | Sometimes metadata is multi-valued and new values should accumulate, rather than overriding previous ones. The // | ||
+ | |||
+ | When its // | ||
+ | |||
+ | The // | ||
+ | |||
+ | ==== Tagging document files ==== | ||
+ | |||
+ | Source documents often need to be structured into sections and subsections, | ||
+ | |||
+ | The simplest way of doing this is often simply to edit the source files. The HTML plugin has a // | ||
+ | |||
+ | < | ||
+ | <!-- | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | --> | ||
+ | </ | ||
+ | |||
+ | //(text of section goes here)// | ||
+ | |||
+ | < | ||
+ | <!-- | ||
+ | </ | ||
+ | --> | ||
+ | </ | ||
+ | |||
+ | The %!-- … --% markers are used because they indicate comments in HTML; thus these section tags will not affect document formatting. In the // | ||
+ | |||
+ | //(text of first part of section goes here)// | ||
+ | |||
+ | < | ||
+ | <!-- | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | --> | ||
+ | </ | ||
+ | |||
+ | //(text of subsection goes here)// | ||
+ | |||
+ | < | ||
+ | <!-- | ||
+ | </ | ||
+ | --> | ||
+ | </ | ||
+ | |||
+ | //(text of last part of section goes here)// | ||
+ | |||
+ | This functionality is inherited by any plugins that use HTMLPlug. In particular, the Word plugin converts its input to HTML form, and so exactly the same way of specifying metadata can be used in Word (and RTF) files. (This involves a bit of work behind the scenes, because when Word documents are converted to HTML care is normally taken to neutralize HTML's special interpretation of stray “<” and “>” signs; we have arranged to override this in the case of the above specifications.) Note that exactly the same format as above is used, even in Word files, including the surrounding “%!--” and “--%”. Font and spacing is ignored. | ||
+ | |||
+ | ===== Classifiers ===== | ||
+ | |||
+ | Classifiers are used to create a collection' | ||
+ | |||
+ | < | ||
+ | {{..: | ||
+ | |||
+ | Classifiers, | ||
+ | |||
+ | < | ||
+ | {{..: | ||
+ | |||
+ | A simpler classifier, called //List//, illustrated in Figure <imgref figure_list_classifier>, | ||
+ | |||
+ | < | ||
+ | {{..: | ||
+ | |||
+ | Other classifiers generate browsing structures that are explicitly hierarchical. Hierarchical classifications are useful for subject classifications and subclassifications, | ||
+ | |||
+ | < | ||
+ | {{..: | ||
+ | |||
+ | All classifiers generate a hierarchical structure that is used to display a browsing index. The lowest levels (i.e. leaves) of the hierarchy are usually documents, but in some classifiers they are sections. The internal nodes of the hierarchy are either //Vlist//, //Hlist//, or // | ||
+ | |||
+ | The lines used to specify classifiers in collection configuration files contain a // | ||
+ | |||
+ | < | ||
+ | |< - 132 92 305 >| | ||
+ | | | **Argument** | **Purpose** | | ||
+ | | // | ||
+ | | | //hfile// | Classification file | | ||
+ | | | // | ||
+ | | | //sort// | Metadata element used to sort documents within leaves (defaults to //Title//) | | ||
+ | | | // | ||
+ | | //List// | | Alphabetic list of documents | | ||
+ | | | // | ||
+ | | | // | ||
+ | | // | ||
+ | | //AZList// | | List of documents split into alphabetical ranges | | ||
+ | | | // | ||
+ | | | // | ||
+ | | // | ||
+ | | // | ||
+ | |||
+ | The current set of classifiers is listed in Table <tblref table_greenstone_classifiers> | ||
+ | |||
+ | All classifiers accept the argument // | ||
+ | |||
+ | Each classifier receives an implicit name from its position in the configuration file. For example, the third classifier specified in the file is called CL3. This is used to name the collection information database fields that define the classifier hierarchy. | ||
+ | |||
+ | Collection-specific classifiers can be written, and are stored in the collection' | ||
+ | |||
+ | ==== List classifiers ==== | ||
+ | |||
+ | The various flavours of list classifier are shown below. | ||
+ | |||
+ | * // | ||
+ | * // | ||
+ | * // | ||
+ | * // | ||
+ | |||
+ | ==== The hierarchy classifier ==== | ||
+ | |||
+ | All classifiers are hierarchical. However, the list classifiers described above have a fixed number of levels, whereas the “hierarchy” classifiers described in this section have an arbitrary number of levels. Hierarchy classifiers are more complex to specify than list classifiers. | ||
+ | |||
+ | < | ||
+ | < | ||
+ | 1 | ||
+ | 1.2 | ||
+ | 2 | ||
+ | 2.1 | ||
+ | 2.2 | ||
+ | 2.3 | ||
+ | 2.4 | ||
+ | 2.5 | ||
+ | 2.6 | ||
+ | 2.6.1 | ||
+ | 2.6.2 | ||
+ | 2.6.3 | ||
+ | 2.6.5 | ||
+ | 2.7 | ||
+ | 2.8 | ||
+ | 2.9 | ||
+ | </ | ||
+ | |||
+ | |||
+ | |||
+ | The //hfile// argument gives the name of a file, like that in Figure <imgref figure_part_of_the_file_sub>, | ||
+ | |||
+ | * Identifier, which matches the value of the metadata (given by the // | ||
+ | * Position-in-hierarchy marker, in multi-part numeric form, e.g. 2, 2.12, 2.12.6. | ||
+ | * The name of the classification. (If this contains spaces, it should be placed in quotation marks.) | ||
+ | |||
+ | Figure <imgref figure_part_of_the_file_sub> | ||
+ | |||
+ | The // | ||
+ | |||
+ | ==== How classifiers work ==== | ||
+ | |||
+ | Classifiers are Perl objects, derived from // | ||
+ | |||
+ | - The //new// method creates the classifier object. | ||
+ | - The //init// method initialises the object with parameters such as metadata type, button name and sort criterion. | ||
+ | - The // | ||
+ | - The // | ||
+ | |||
+ | The // | ||
+ | |||
+ | The build process initialises the classifiers as soon as the //builder// object is created. Classifications are created during the build phase, when the information database is created, by // | ||
+ | |||
+ | < | ||
+ | |< - 132 397 >| | ||
+ | | //[Text]// | The document' | ||
+ | | //[link] … [/link]// | The html to link to the document itself | | ||
+ | | //[icon]// | An appropriate icon (e.g. the little text icon in a //Search Results// string) | | ||
+ | | //[num]// | The document number (useful for debugging). | | ||
+ | | // | ||
+ | |||
+ | ===== Formatting Greenstone output ===== | ||
+ | |||
+ | The web pages you see when using Greenstone are not pre-stored but are generated “on the fly” as they are needed. The appearance of many aspects of the pages is controlled using “format strings.” Format strings belong in the collection configuration file, introduced by the keyword //format// followed by the name of the element to which the format applies. There are two different kinds of page element that are controlled by format strings. The first comprises the items on the page that show documents or parts of documents. The second comprises the lists produced by classifiers and searches. All format strings are interpreted at the time that pages are displayed. Since they take effect as soon as any changes in // | ||
+ | |||
+ | Table <tblref table_items_appearing_in_format_strings> | ||
+ | |||
+ | < | ||
+ | |< - 246 283 >| | ||
+ | | //format DocumentImages true/ | ||
+ | | //format DocumentHeading formatstring// | ||
+ | | //format DocumentContents true/ | ||
+ | | //format DocumentButtons string// | Controls the buttons that are displayed on a document page (default // | ||
+ | | //format DocumentText formatstring// | ||
+ | | //format DocumentArrowsBottom true/ | ||
+ | | //format DocumentUseHTML true/ | ||
+ | |||
+ | ==== Formatting Greenstone lists ==== | ||
+ | |||
+ | Format strings that control how lists look can apply at different levels of the display structure. They can alter all lists of a certain type within a collection (for example // | ||
+ | |||
+ | Following the keyword //format// is a two-part keyword, only one part of which is mandatory. The first part identifies the list to which the format applies. The list generated by a search is called //Search//, while the lists generated by classifiers are called //CL1, CL2, CL3,…// for the first, second, third,… classifier specified in // | ||
+ | |||
+ | > //format CL4VList ...// applies to all //VLists// in CL4 | ||
+ | |||
+ | > //format CL2HList ...// applies to all //HLists// in CL2 | ||
+ | |||
+ | > //format CL1DateList ...// applies to all // | ||
+ | |||
+ | > //format SearchVList ...// applies to the Search Results list | ||
+ | |||
+ | > //format CL3 ...// applies to all nodes in CL3, unless otherwise specified | ||
+ | |||
+ | > //format VList ...// applies to all //VLists// in all classifiers, | ||
+ | |||
+ | The “...” in these examples stand for html format specifications that control the information, | ||
+ | |||
+ | Recall that all classifiers produce hierarchies. Each level of the hierarchy is displayed in one of four possible ways. We have already encountered //HList//, //VList//, and // | ||
+ | |||
+ | ==== Examples of classifiers and format strings ==== | ||
+ | |||
+ | < | ||
+ | <code 1> | ||
+ | classify Hierarchy -hfile sub.txt -metadata Subject -sort Title | ||
+ | classify AZList | ||
+ | classify Hierarchy -hfile org.txt -metadata Organisation -sort Title | ||
+ | classify List | ||
+ | format SearchVList " <td valign=top [link][icon][/ | ||
+ | | ||
+ | | ||
+ | format CL4Vlist | ||
+ | format DocumentImages | ||
+ | format DocumentText | ||
+ | format DocumentButtons " Expand Text|Expand contents|Detach|Highlight" | ||
+ | </ | ||
+ | |||
+ | |||
+ | |||
+ | Figure <imgref figure_excerpt_from_the_demo_collection_collect> | ||
+ | |||
+ | Line 4 specifies the Demo collection' | ||
+ | |||
+ | Line 1 specifies the Demo collection' | ||
+ | |||
+ | Line 2 specifies the remaining classification for the Demo collection, //Titles A-Z// (CL2). Note that there are no corresponding format strings for the classifiers CL1 -CL3. Greenstone has built-in defaults for each format string type and so it's not necessary to set a format string unless you want to override the default. | ||
+ | |||
+ | < | ||
+ | {{..: | ||
+ | |||
+ | This accounts for the four // | ||
+ | |||
+ | < | ||
+ | {{..: | ||
+ | |||
+ | Line 5 of Figure <imgref figure_excerpt_from_the_demo_collection_collect> | ||
+ | |||
+ | < | ||
+ | <td valign=top> | ||
+ | < | ||
+ | </ | ||
+ | |||
+ | This is designed to appear as a table row, which is how the query results list is formatted. It gives a small icon linked to the text, as usual, and the document title, hyperlinked to the document itself. | ||
+ | |||
+ | In this collection, documents are hierarchical. In fact, the above hyperlink anchor evaluates to the title of the section returned by the query. However, it would be better to augment it with the title of the enclosing section, the enclosing chapter, and the book in which it occurs. There is a special metadata item, //parent//, which is not stored in documents but is implicit in any hierarchical document, that produces such a list. It either returns the parent document, or, if used with the qualifier //All//, the list of hierarchically enclosing parents, separated by a character string that can be given after the //All// qualifier. Thus | ||
+ | |||
+ | < | ||
+ | <td valign=top> | ||
+ | </ | ||
+ | |||
+ | has the effect of producing a list containing the book title, chapter title, etc. that enclose the target section, separated by colons, with a further colon followed by a hyperlink to the target section' | ||
+ | |||
+ | Unfortunately, | ||
+ | |||
+ | < | ||
+ | {If}{[metadata], | ||
+ | {Or}{action, | ||
+ | </ | ||
+ | |||
+ | In either case curly brackets are used to signal that the statements should be interpreted and not just printed out as text. The //If// tests whether the metadata is empty and takes the first clause if not, otherwise the second one (if it exists). Any metadata item can be used, including the special metadata //parent//. The //Or// statement evaluates each action in turn until one is found that is non-null. That one is sent to the output and the remaining actions are skipped. | ||
+ | |||
+ | Returning to line 5 of Figure <imgref figure_excerpt_from_the_demo_collection_collect>, | ||
+ | |||
+ | < | ||
+ | <td valign=top> | ||
+ | < | ||
+ | | ||
+ | [link][Title][/ | ||
+ | </ | ||
+ | |||
+ | This precedes the //parent// specification with a conditional that checks whether the result is empty and only outputs the parent string when it is present. Incidentally, | ||
+ | |||
+ | Some final examples illustrate other features. The // | ||
+ | |||
+ | < | ||
+ | classify AZSectionList metadata=Creator | ||
+ | format CL2Vlist "< | ||
+ | </ | ||
+ | |||
+ | The format specification shows these //VLists// in the appropriate way. | ||
+ | |||
+ | The format-string mechanism is flexible but tricky to learn. The best way is by studying existing collection configuration files. | ||
+ | |||
+ | ==== Linking to different document versions ==== | ||
+ | |||
+ | Using the //[link] … [/link]// mechanism in a format string inserts a hyperlink to the text of a document, and when the link is clicked the html version of the document is displayed. In some collections, | ||
+ | |||
+ | The key to being able to show different versions of a document is to embed the necessary information about where the other versions reside into the Greenstone archive form of the document. The information is represented in the form of metadata. Recall that putting | ||
+ | |||
+ | < | ||
+ | [link][Title][/ | ||
+ | </ | ||
+ | |||
+ | into a format string creates a link to the html form of the document, whose anchor text is the document' | ||
+ | |||
+ | < | ||
+ | [srclink][Title][/ | ||
+ | </ | ||
+ | |||
+ | into a format string, a link is created to the Word or PDF form of the document; again the anchor in this example is the document' | ||
+ | |||
+ | < | ||
+ | [srclink][srcicon][/ | ||
+ | </ | ||
+ | |||
+ | creates a link which is labeled by the standard Word or PDF icon (whichever is appropriate), | ||
+ | |||
+ | ===== Controlling the Greenstone user interface ===== | ||
+ | |||
+ | The entire Greenstone user interface is controlled by macros which reside in the // | ||
+ | |||
+ | Web pages are generated on the fly for a number of reasons, and the macro system is how Greenstone implements the necessary flexibility. Pages can be presented in many languages, and a different macro file is used to store all the interface text in each language. When Greenstone displays a page the macro interpreter checks a language variable and loads the page in the appropriate language (this does not, unfortunately, | ||
+ | |||
+ | ==== The macro file format ==== | ||
+ | |||
+ | Macro files have a //.dm// extension. Each file defines one or more // | ||
+ | |||
+ | Macros have names that begin and end with an underscore, and their content is defined using curly brackets. Content can be plain text, html (including links to Java applets and JavaScript), | ||
+ | |||
+ | < | ||
+ | _content_ {< | ||
+ | </ | ||
+ | |||
+ | The page will read “Oops” at the top, and // | ||
+ | |||
+ | // | ||
+ | |||
+ | < | ||
+ | _collectionextra_ {This collection contains _about: | ||
+ | </ | ||
+ | |||
+ | comes from // | ||
+ | |||
+ | Macros often contain conditional statements. They resemble the format string conditional described above, though their appearance is slightly different. The basic format is // | ||
+ | |||
+ | < | ||
+ | _imagecollection_ { | ||
+ | _If_( " | ||
+ | <a href = " | ||
+ | < | ||
+ | </ | ||
+ | | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | This looks rather obscure. // | ||
+ | |||
+ | Macros can take arguments. Here is a second definition for the // | ||
+ | |||
+ | < | ||
+ | _imagecollection_[v=1]{_imagecollectionv_} | ||
+ | </ | ||
+ | |||
+ | The argument //[v=1]// specifies that the second definition is used when Greenstone is running in text-only mode. The language macros work similarly—apart from // | ||
+ | |||
+ | < | ||
+ | _textimagehome_ {Home Page} | ||
+ | </ | ||
+ | |||
+ | appears in the English language macro file, whereas the German version is | ||
+ | |||
+ | < | ||
+ | _textimagehome_ [l=de] {Hauptaseite} | ||
+ | </ | ||
+ | |||
+ | The English and German versions are in the same package, though they are in separate files (package definitions may span more than one file). Greenstone uses its //l// argument at run time to determine which language to display. | ||
+ | |||
+ | < | ||
+ | < | ||
+ | package about | ||
+ | ############################################## | ||
+ | # about page content | ||
+ | ############################################### | ||
+ | _pagetitle_ {_collectionname_} | ||
+ | _content_ { | ||
+ | < | ||
+ | _navigationbar_ | ||
+ | </ | ||
+ | _query: | ||
+ | < | ||
+ | < | ||
+ | _textsubcollections_ | ||
+ | < | ||
+ | _help: | ||
+ | } | ||
+ | _textabout_ { | ||
+ | < | ||
+ | _Global: | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | |||
+ | |||
+ | As a final example, Figure <imgref figure_part_of_the_aboutdm_macro_file> | ||
+ | |||
+ | ==== Using macros ==== | ||
+ | |||
+ | Macros are powerful, and can be a little obscure. However, with a good knowledge of html and a bit of practice, they become a quick and easy way to customise your Greenstone site. | ||
+ | |||
+ | For example, suppose you wanted to create a static page that looked like your current Greenstone site. You could create a new package, called //static//, for example, in a new file, and override the // | ||
+ | |||
+ | To change the “look and feel” of Greenstone you can edit the //base// and //style// packages. To change the Greenstone home page, edit the //home// package (this is described in the // | ||
+ | |||
+ | Experiment freely with macros. Changes appear instantly, because macros are interpreted as pages are displayed. The macro language is a useful tool that can be used to make your Greenstone site your own. | ||
+ | |||
+ | ===== The packages directory ===== | ||
+ | |||
+ | < | ||
+ | |< - 132 217 180 >| | ||
+ | | | **Package** | **URL** | | ||
+ | | //mg// | mg, short for “Managing Gigabytes.” Compression, | ||
+ | | //wget// | Web mirroring software for use with Greenstone. Written in C++ | // www.tuwien.ac.at/ | ||
+ | | //w3mir// | A web mirroring program written in Perl. This is not Greenstone' | ||
+ | | //windows// | Packages used when running under Windows. | //—// | | ||
+ | | // | ||
+ | | // | ||
+ | | // | ||
+ | | //wv// | Microsoft Word converter (for building collections from Word documents) slimmed down for Greenstone. | // | ||
+ | | // | ||
+ | | //yaz// | Z39.50 client program being used for research in making Greenstone Z39.50 compliant. Progress is reported in the // | ||
+ | |||
+ | The // | ||
legacy/manuals/en/develop/getting_the_most_out_of_your_documents.txt · Last modified: 2023/03/13 01:46 by 127.0.0.1