xindy Manual: Processing Phases

From abdd2d2892b5ee0071ef7bf1a387251d74e78055 Mon Sep 17 00:00:00 2001 From: Vladimir Volovich Date: Tue, 18 Mar 2008 00:00:20 +0000 Subject: *original* xindy-2.3 sources downloaded from http://surfnet.dl.sourceforge.net/sourceforge/xindy/xindy-2.3.tar.gz except the directory "rte/clisp-2.43/", which contained original clisp-2.43 sources (nearly 48 MB), is removed. git-svn-id: svn://tug.org/texlive/trunk@7003 c570f23f-e606-0410-a88d-b1316a301751 --- Build/source/utils/xindy/doc/manual-4.html | 230 +++++++++++++++++++++++++++++ 1 file changed, 230 insertions(+) create mode 100644 Build/source/utils/xindy/doc/manual-4.html (limited to 'Build/source/utils/xindy/doc/manual-4.html') diff --git a/Build/source/utils/xindy/doc/manual-4.html b/Build/source/utils/xindy/doc/manual-4.html new file mode 100644 index 00000000000..6d39d7ba240 --- /dev/null +++ b/Build/source/utils/xindy/doc/manual-4.html @@ -0,0 +1,230 @@ + + + + + xindy Manual: Processing Phases + + + + + +Next +Previous +Contents +

4. Processing Phases

+ +

4.1 The Startup Phase +

+ +

After the system is started, xindy reads in the index style that +is passed as a command line argument. Each require command is +executed and the internal data structures representing the index style +are built up. The index style must completely be read in before the +raw index can be read. +

4.2 The Processing Phase +

+ +

The processing phase starts with reading the complete raw index. The +name of the raw index file must be passed via the command line. All +index entries are read in and pre-processed. All attributes and +cross reference classes are checked if they are already known to the +system. All strings representing location references are matched +against all known location classes. Appropriate warnings are issued, +if errors are encountered. +

After the raw index has completely been read in, the +location references of each index entry are merged, separated and +sorted and the building of ranges takes place. This phase is the most +complex one and we will describe it in detail. +

All location references are separated according to the class +they belong to. These groups are called location class groups. +Possible groups are all defined location and crossref classes. See +the commands define-location-class and +define-crossref-class for a description how these classes can +be defined. + +The classes are sorted according to an order that can be defined with +the command define-location-class-order. +
The further processing of each location class group is +different for the location classes and the crossref classes. + +
- Cross references are sorted lexicographically based on +the ISO-Latin alphabet. + +
- To illustrate the processing of location references we assume +the following list: + +
  + 13, 14, 15, 18, 12, 13, +14, 16, 14, 16 +
  + + +The location references in italics own the attribute `important, +those with in boldface have attribute `definition', and all others +are own the attribute `default'. Imagine, the attribute groups were +defined with the commands + +
  ++ (define-attribute-groups (("definition" "important") + ("default"))) + + (merge-to "definition" "default" :drop) + + +
  + + +See commands define-attributes and merge-to for a +detailed description. + +The substitution rules are applied. This means that +location references 13 and 14 with attribute `important' +are substituted by the location references 13 and 14 +with attribute `definition'. Substitution means removing from the +list of location references. + +Substitution occurs because the definition of the attribute groups +implicitly defines "definition" substitutes +"important". + +The resulting list is now + +
  + 13, 14, 15, 18, 12, 16, 14, +16 +
  + + + The merge-to rules are applied. +Their meaning is to make location references appear with another +attribute as well, but only in the function of supporting the +building of ranges. They disappear after the ranges are built. The +location references that cause new location refererences to be +added are called parents, whereas the new ones are called +childs. The example rule results in the adding of all +refernces with attribute `definition' to the attribute `default' +which results in the list + +
  + 13, 14, 15, 18, 12, 16, (13), +14, (15), 16, (18) +
  + + +The childs are put in parenthesis since they may only be used to +build up ranges. + +For each attribute we now try to build ranges. Since the switch +:drop was specified we must start with the attribute +`default', because a successful merging of location references may +result in dropping the parents. This results in the range `13--16'. +The childs +(13) and (15) were used in the building of ranges, so their parents +13 and 15 have to be removed from the list of +location references. This step would be omitted if the switch +:drop were not specified. After unsucessfully trying to build +more ranges and dropping the location references 13, 15 +and (18)--which was only meant to build ranges--we obtain the list + +
  +14, 18, 12, 16, 13--16 +
  + + +Finally the attributes are brought into the right order. In our +example the location references of the first attribute group are +merged and sorted lexicographically resulting in two attribute groups + +
  +(12, 14, 16, 18) (13--16) +
  + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+ +

After all index entries have been processed the letter groups are +formed and the index entries and location references are transformed +into tree like structures as defined in the index style. +

4.3 The Markup Phase +

+ +

After the index has completely been processed, the markup phase +traverses the tree-like structure of the index. Each step triggers the +appropriate markup events resulting in the emitting of markup tags. +

+Next +Previous +Contents + + -- cgit v1.2.3