1 files changed, 230 insertions, 0 deletions
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 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <TITLE>xindy Manual: Processing Phases</TITLE>
+ <LINK HREF="manual-5.html" REL=next>
+ <LINK HREF="manual-3.html" REL=previous>
+ <LINK HREF="manual.html#toc4" REL=contents>
+</HEAD>
+<BODY>
+<A HREF="manual-5.html">Next</A>
+<A HREF="manual-3.html">Previous</A>
+<A HREF="manual.html#toc4">Contents</A>
+<HR>
+<H2><A NAME="startup-phase"></A> <A NAME="s4">4. Processing Phases</A></H2>
+
+<H2><A NAME="ss4.1">4.1 The Startup Phase</A>
+</H2>
+
+<P>After the system is started, <SF>xindy</SF> reads in the index style that
+is passed as a command line argument. Each <CODE>require</CODE> 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.
+<P>
+<P>
+<A NAME="processing-phase"></A> <H2><A NAME="ss4.2">4.2 The Processing Phase</A>
+</H2>
+
+<P>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.
+<P>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.
+<P>
+<OL>
+<LI> All location references are separated according to the class
+they belong to. These groups are called <EM>location class groups</EM>.
+Possible groups are all defined location  and crossref classes. See
+the commands <CODE>define-location-class</CODE> and
+<CODE>define-crossref-class</CODE> for a description how these classes can
+be defined.
+
+The classes are sorted according to an order that can be defined with
+the command <CODE>define-location-class-order</CODE>.
+</LI>
+<LI> The further processing of each location class group is
+different for the location classes and the crossref classes.
+
+<UL>
+<LI> Cross references are sorted lexicographically based on
+the ISO-Latin alphabet.
+
+<A NAME="sort-merge-locrefs"></A> </LI>
+<LI> To illustrate the processing of location references we assume
+the following list:
+
+<BLOCKQUOTE>
+ <EM>13</EM>, <EM>14</EM>, <EM>15</EM>, <EM>18</EM>, <B>12</B>, <B>13</B>,
+<B>14</B>, <B>16</B>, 14, 16 
+</BLOCKQUOTE>
+
+
+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
+
+<BLOCKQUOTE><CODE>
+<PRE>
+   (define-attribute-groups (("definition" "important")
+                             ("default")))
+
+   (merge-to "definition" "default" :drop)
+   
+</PRE>
+</CODE></BLOCKQUOTE>
+
+
+See commands <CODE>define-attributes</CODE> and <CODE>merge-to</CODE> for a
+detailed description.
+
+The substitution rules are applied. This means that
+location references <B>13</B> and <B>14</B> with attribute `important'
+are <EM>substituted</EM> by the location references <EM>13</EM> and <EM>14</EM>
+with attribute `definition'. Substitution means removing from the
+list of location references.
+
+Substitution occurs because the definition of the attribute groups
+implicitly defines <CODE>"definition"</CODE> <EM>substitutes</EM>
+<CODE>"important"</CODE>.
+
+The resulting list is now
+
+<BLOCKQUOTE>
+ <EM>13</EM>, <EM>14</EM>, <EM>15</EM>, <EM>18</EM>, <B>12</B>, <B>16</B>, 14,
+16 
+</BLOCKQUOTE>
+
+
+<A NAME="def merge-to"></A>  The <CODE>merge-to</CODE> 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 <EM>parents</EM>, whereas the new ones are called
+<EM>childs</EM>. The example rule results in the adding of all
+refernces with attribute `definition' to the attribute `default'
+which results in the list
+
+<BLOCKQUOTE>
+ <EM>13</EM>, <EM>14</EM>, <EM>15</EM>, <EM>18</EM>, <B>12</B>, <B>16</B>, (13),
+14, (15), 16, (18) 
+</BLOCKQUOTE>
+
+
+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
+<CODE>:drop</CODE> 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
+<EM>13</EM> and <EM>15</EM> have to be removed from the list of
+location references. This step would be omitted if the switch
+<CODE>:drop</CODE> were not specified. After unsucessfully trying to build
+more ranges and dropping the location references <EM>13</EM>, <EM>15</EM>
+and (18)--which was only meant to build ranges--we obtain the list
+
+<BLOCKQUOTE>
+<EM>14</EM>, <EM>18</EM>, <B>12</B>, <B>16</B>, 13--16
+</BLOCKQUOTE>
+
+
+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
+
+<BLOCKQUOTE>
+(<B>12</B>, <EM>14</EM>, <B>16</B>, <EM>18</EM>) (13--16)
+</BLOCKQUOTE>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+</LI>
+</UL>
+
+</LI>
+</OL>
+<P>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.
+<P>
+<P>
+<P>
+<A NAME="markup-phase"></A> <H2><A NAME="ss4.3">4.3 The Markup Phase</A>
+</H2>
+
+<P>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.
+<P>
+<P>
+<P>
+<HR>
+<A HREF="manual-5.html">Next</A>
+<A HREF="manual-3.html">Previous</A>
+<A HREF="manual.html#toc4">Contents</A>
+</BODY>
+</HTML>