/usr/share/doc/xindy-rules/manual-4.html is in xindy-rules 2.4-1.1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 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>
|