summaryrefslogtreecommitdiff
path: root/Build/source/utils/xindy/doc
diff options
context:
space:
mode:
Diffstat (limited to 'Build/source/utils/xindy/doc')
-rw-r--r--Build/source/utils/xindy/doc/Makefile.am62
-rw-r--r--Build/source/utils/xindy/doc/Makefile.in479
-rw-r--r--Build/source/utils/xindy/doc/README14
-rw-r--r--Build/source/utils/xindy/doc/dataflow.gifbin0 -> 1988 bytes
-rw-r--r--Build/source/utils/xindy/doc/faq-1.html169
-rw-r--r--Build/source/utils/xindy/doc/faq-2.html95
-rw-r--r--Build/source/utils/xindy/doc/faq-3.html83
-rw-r--r--Build/source/utils/xindy/doc/faq-4.html668
-rw-r--r--Build/source/utils/xindy/doc/faq.html90
-rw-r--r--Build/source/utils/xindy/doc/index.gifbin0 -> 9066 bytes
-rw-r--r--Build/source/utils/xindy/doc/makeindex4.pdfbin0 -> 5054 bytes
-rw-r--r--Build/source/utils/xindy/doc/manual-1.html42
-rw-r--r--Build/source/utils/xindy/doc/manual-2.html302
-rw-r--r--Build/source/utils/xindy/doc/manual-3.html1160
-rw-r--r--Build/source/utils/xindy/doc/manual-4.html230
-rw-r--r--Build/source/utils/xindy/doc/manual-5.html63
-rw-r--r--Build/source/utils/xindy/doc/manual-6.html53
-rw-r--r--Build/source/utils/xindy/doc/manual-7.html53
-rw-r--r--Build/source/utils/xindy/doc/manual.html73
-rw-r--r--Build/source/utils/xindy/doc/mappings.gifbin0 -> 878 bytes
-rw-r--r--Build/source/utils/xindy/doc/next.gifbin0 -> 172 bytes
-rw-r--r--Build/source/utils/xindy/doc/prev.gifbin0 -> 220 bytes
-rw-r--r--Build/source/utils/xindy/doc/style-tutorial-1.html92
-rw-r--r--Build/source/utils/xindy/doc/style-tutorial-2.html361
-rw-r--r--Build/source/utils/xindy/doc/style-tutorial-3.html263
-rw-r--r--Build/source/utils/xindy/doc/style-tutorial-4.html41
-rw-r--r--Build/source/utils/xindy/doc/style-tutorial.html66
-rw-r--r--Build/source/utils/xindy/doc/style-tutorial/Makefile.am38
-rw-r--r--Build/source/utils/xindy/doc/style-tutorial/Makefile.in317
-rw-r--r--Build/source/utils/xindy/doc/style-tutorial/ex1.raw20
-rw-r--r--Build/source/utils/xindy/doc/style-tutorial/ex1.tex16
-rw-r--r--Build/source/utils/xindy/doc/style-tutorial/ex2.raw35
-rw-r--r--Build/source/utils/xindy/doc/style-tutorial/ex2.tex16
-rw-r--r--Build/source/utils/xindy/doc/style-tutorial/index.tex16
-rw-r--r--Build/source/utils/xindy/doc/style-tutorial/style1.xdy55
-rw-r--r--Build/source/utils/xindy/doc/style-tutorial/style2.xdy80
-rw-r--r--Build/source/utils/xindy/doc/tex2xindy.pdfbin0 -> 4825 bytes
-rw-r--r--Build/source/utils/xindy/doc/texindy.pdfbin0 -> 12313 bytes
-rw-r--r--Build/source/utils/xindy/doc/toc.gifbin0 -> 145 bytes
-rw-r--r--Build/source/utils/xindy/doc/xindy.pdfbin0 -> 11444 bytes
-rw-r--r--Build/source/utils/xindy/doc/xindy.v2.pdfbin0 -> 8507 bytes
41 files changed, 5052 insertions, 0 deletions
diff --git a/Build/source/utils/xindy/doc/Makefile.am b/Build/source/utils/xindy/doc/Makefile.am
new file mode 100644
index 00000000000..fe89369a952
--- /dev/null
+++ b/Build/source/utils/xindy/doc/Makefile.am
@@ -0,0 +1,62 @@
+## Use `autoreconf' in top-level directory to recreate all
+## autoconf/automake files.
+## Or, call `automake Makefile' to create only Makefile.in.
+
+## Copyright (C) 2004-2005 by Gour.
+##
+## This program is free software; you can redistribute it and/or
+## modify it under the terms of the GNU General Public License as
+## published by the Free Software Foundation; either version 2 of the
+## License, or (at your option) any later version.
+##
+## This program is distributed in the hope that it will be useful, but
+## WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+## General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program in the file COPYING; if not, write to the
+## Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+## Boston, MA 02110-1301 USA.
+
+SUBDIRS = style-tutorial
+
+docdir = $(datadir)/doc/$(PACKAGE_NAME)-$(PACKAGE_VERSION)
+
+
+FILES = \
+ dataflow.gif \
+ faq-1.html \
+ faq-2.html \
+ faq-3.html \
+ faq-4.html \
+ faq.html \
+ index.gif \
+ makeindex4.pdf \
+ manual-1.html \
+ manual-2.html \
+ manual-3.html \
+ manual-4.html \
+ manual-5.html \
+ manual-6.html \
+ manual-7.html \
+ manual.html \
+ mappings.gif \
+ next.gif \
+ prev.gif \
+ README \
+ style-tutorial-1.html \
+ style-tutorial-2.html \
+ style-tutorial-3.html \
+ style-tutorial-4.html \
+ style-tutorial.html \
+ tex2xindy.pdf \
+ texindy.pdf \
+ toc.gif \
+ xindy.pdf
+
+EXTRA_DIST = $(FILES)
+
+doc_DATA = $(FILES)
+
+
diff --git a/Build/source/utils/xindy/doc/Makefile.in b/Build/source/utils/xindy/doc/Makefile.in
new file mode 100644
index 00000000000..dfb89873503
--- /dev/null
+++ b/Build/source/utils/xindy/doc/Makefile.in
@@ -0,0 +1,479 @@
+# Makefile.in generated by automake 1.9.6 from Makefile.am.
+# @configure_input@
+
+# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
+# 2003, 2004, 2005 Free Software Foundation, Inc.
+# This Makefile.in is free software; the Free Software Foundation
+# gives unlimited permission to copy and/or distribute it,
+# with or without modifications, as long as this notice is preserved.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
+# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
+# PARTICULAR PURPOSE.
+
+@SET_MAKE@
+
+srcdir = @srcdir@
+top_srcdir = @top_srcdir@
+VPATH = @srcdir@
+pkgdatadir = $(datadir)/@PACKAGE@
+pkglibdir = $(libdir)/@PACKAGE@
+pkgincludedir = $(includedir)/@PACKAGE@
+top_builddir = ..
+am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
+INSTALL = @INSTALL@
+install_sh_DATA = $(install_sh) -c -m 644
+install_sh_PROGRAM = $(install_sh) -c
+install_sh_SCRIPT = $(install_sh) -c
+INSTALL_HEADER = $(INSTALL_DATA)
+transform = $(program_transform_name)
+NORMAL_INSTALL = :
+PRE_INSTALL = :
+POST_INSTALL = :
+NORMAL_UNINSTALL = :
+PRE_UNINSTALL = :
+POST_UNINSTALL = :
+build_triplet = @build@
+host_triplet = @host@
+subdir = doc
+DIST_COMMON = $(srcdir)/Makefile.in $(srcdir)/Makefile.am
+ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
+am__aclocal_m4_deps = $(top_srcdir)/m4/ac_prog_latex.m4 \
+ $(top_srcdir)/m4/ac_prog_pdflatex.m4 \
+ $(top_srcdir)/configure.ac
+am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
+ $(ACLOCAL_M4)
+mkinstalldirs = $(install_sh) -d
+CONFIG_CLEAN_FILES =
+SOURCES =
+RECURSIVE_TARGETS = all-recursive check-recursive dvi-recursive \
+ html-recursive info-recursive install-data-recursive \
+ install-exec-recursive install-info-recursive \
+ install-recursive installcheck-recursive installdirs-recursive \
+ pdf-recursive ps-recursive uninstall-info-recursive \
+ uninstall-recursive
+am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
+am__vpath_adj = case $$p in \
+ $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
+ *) f=$$p;; \
+ esac;
+am__strip_dir = `echo $$p | sed -e 's|^.*/||'`;
+am__installdirs = "$(DESTDIR)$(docdir)"
+docDATA_INSTALL = $(INSTALL_DATA)
+DATA = $(doc_DATA)
+ETAGS = etags
+CTAGS = ctags
+DIST_SUBDIRS = $(SUBDIRS)
+ACLOCAL = @ACLOCAL@
+AMDEP_FALSE = @AMDEP_FALSE@
+AMDEP_TRUE = @AMDEP_TRUE@
+AMTAR = @AMTAR@
+AUTOCONF = @AUTOCONF@
+AUTOHEADER = @AUTOHEADER@
+AUTOMAKE = @AUTOMAKE@
+AWK = @AWK@
+BUILDDOCS_FALSE = @BUILDDOCS_FALSE@
+BUILDDOCS_TRUE = @BUILDDOCS_TRUE@
+BUILDRULES_FALSE = @BUILDRULES_FALSE@
+BUILDRULES_TRUE = @BUILDRULES_TRUE@
+CC = @CC@
+CCDEPMODE = @CCDEPMODE@
+CFLAGS = @CFLAGS@
+CLISP_DIR = @CLISP_DIR@
+CLISP_PATH = @CLISP_PATH@
+CPP = @CPP@
+CPPFLAGS = @CPPFLAGS@
+CXX = @CXX@
+CXXDEPMODE = @CXXDEPMODE@
+CXXFLAGS = @CXXFLAGS@
+CYGPATH_W = @CYGPATH_W@
+DEFS = @DEFS@
+DEPDIR = @DEPDIR@
+ECHO_C = @ECHO_C@
+ECHO_N = @ECHO_N@
+ECHO_T = @ECHO_T@
+EGREP = @EGREP@
+EXEEXT = @EXEEXT@
+EXT_CLISP_FALSE = @EXT_CLISP_FALSE@
+EXT_CLISP_TRUE = @EXT_CLISP_TRUE@
+INSTALL_DATA = @INSTALL_DATA@
+INSTALL_PROGRAM = @INSTALL_PROGRAM@
+INSTALL_SCRIPT = @INSTALL_SCRIPT@
+INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
+LDFLAGS = @LDFLAGS@
+LEX = @LEX@
+LEXLIB = @LEXLIB@
+LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
+LIBOBJS = @LIBOBJS@
+LIBS = @LIBS@
+LN_S = @LN_S@
+LTLIBOBJS = @LTLIBOBJS@
+MAKEINFO = @MAKEINFO@
+OBJEXT = @OBJEXT@
+PACKAGE = @PACKAGE@
+PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
+PACKAGE_NAME = @PACKAGE_NAME@
+PACKAGE_STRING = @PACKAGE_STRING@
+PACKAGE_TARNAME = @PACKAGE_TARNAME@
+PACKAGE_VERSION = @PACKAGE_VERSION@
+PATH_SEPARATOR = @PATH_SEPARATOR@
+SET_MAKE = @SET_MAKE@
+SHELL = @SHELL@
+STRIP = @STRIP@
+VERSION = @VERSION@
+YACC = @YACC@
+ac_ct_CC = @ac_ct_CC@
+ac_ct_CXX = @ac_ct_CXX@
+ac_ct_STRIP = @ac_ct_STRIP@
+am__fastdepCC_FALSE = @am__fastdepCC_FALSE@
+am__fastdepCC_TRUE = @am__fastdepCC_TRUE@
+am__fastdepCXX_FALSE = @am__fastdepCXX_FALSE@
+am__fastdepCXX_TRUE = @am__fastdepCXX_TRUE@
+am__include = @am__include@
+am__leading_dot = @am__leading_dot@
+am__quote = @am__quote@
+am__tar = @am__tar@
+am__untar = @am__untar@
+bindir = @bindir@
+build = @build@
+build_alias = @build_alias@
+build_cpu = @build_cpu@
+build_os = @build_os@
+build_vendor = @build_vendor@
+datadir = @datadir@
+exec_prefix = @exec_prefix@
+host = @host@
+host_alias = @host_alias@
+host_cpu = @host_cpu@
+host_os = @host_os@
+host_vendor = @host_vendor@
+includedir = @includedir@
+infodir = @infodir@
+install_sh = @install_sh@
+latex = @latex@
+libdir = @libdir@
+libexecdir = @libexecdir@
+localstatedir = @localstatedir@
+mandir = @mandir@
+mkdir_p = @mkdir_p@
+oldincludedir = @oldincludedir@
+pdflatex = @pdflatex@
+prefix = @prefix@
+program_transform_name = @program_transform_name@
+sbindir = @sbindir@
+sharedstatedir = @sharedstatedir@
+sysconfdir = @sysconfdir@
+target_alias = @target_alias@
+SUBDIRS = style-tutorial
+docdir = $(datadir)/doc/$(PACKAGE_NAME)-$(PACKAGE_VERSION)
+FILES = \
+ dataflow.gif \
+ faq-1.html \
+ faq-2.html \
+ faq-3.html \
+ faq-4.html \
+ faq.html \
+ index.gif \
+ makeindex4.pdf \
+ manual-1.html \
+ manual-2.html \
+ manual-3.html \
+ manual-4.html \
+ manual-5.html \
+ manual-6.html \
+ manual-7.html \
+ manual.html \
+ mappings.gif \
+ next.gif \
+ prev.gif \
+ README \
+ style-tutorial-1.html \
+ style-tutorial-2.html \
+ style-tutorial-3.html \
+ style-tutorial-4.html \
+ style-tutorial.html \
+ tex2xindy.pdf \
+ texindy.pdf \
+ toc.gif \
+ xindy.pdf
+
+EXTRA_DIST = $(FILES)
+doc_DATA = $(FILES)
+all: all-recursive
+
+.SUFFIXES:
+$(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(am__configure_deps)
+ @for dep in $?; do \
+ case '$(am__configure_deps)' in \
+ *$$dep*) \
+ cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh \
+ && exit 0; \
+ exit 1;; \
+ esac; \
+ done; \
+ echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign doc/Makefile'; \
+ cd $(top_srcdir) && \
+ $(AUTOMAKE) --foreign doc/Makefile
+.PRECIOUS: Makefile
+Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
+ @case '$?' in \
+ *config.status*) \
+ cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
+ *) \
+ echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
+ cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
+ esac;
+
+$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
+ cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
+
+$(top_srcdir)/configure: $(am__configure_deps)
+ cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
+$(ACLOCAL_M4): $(am__aclocal_m4_deps)
+ cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
+uninstall-info-am:
+install-docDATA: $(doc_DATA)
+ @$(NORMAL_INSTALL)
+ test -z "$(docdir)" || $(mkdir_p) "$(DESTDIR)$(docdir)"
+ @list='$(doc_DATA)'; for p in $$list; do \
+ if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
+ f=$(am__strip_dir) \
+ echo " $(docDATA_INSTALL) '$$d$$p' '$(DESTDIR)$(docdir)/$$f'"; \
+ $(docDATA_INSTALL) "$$d$$p" "$(DESTDIR)$(docdir)/$$f"; \
+ done
+
+uninstall-docDATA:
+ @$(NORMAL_UNINSTALL)
+ @list='$(doc_DATA)'; for p in $$list; do \
+ f=$(am__strip_dir) \
+ echo " rm -f '$(DESTDIR)$(docdir)/$$f'"; \
+ rm -f "$(DESTDIR)$(docdir)/$$f"; \
+ done
+
+# This directory's subdirectories are mostly independent; you can cd
+# into them and run `make' without going through this Makefile.
+# To change the values of `make' variables: instead of editing Makefiles,
+# (1) if the variable is set in `config.status', edit `config.status'
+# (which will cause the Makefiles to be regenerated when you run `make');
+# (2) otherwise, pass the desired values on the `make' command line.
+$(RECURSIVE_TARGETS):
+ @failcom='exit 1'; \
+ for f in x $$MAKEFLAGS; do \
+ case $$f in \
+ *=* | --[!k]*);; \
+ *k*) failcom='fail=yes';; \
+ esac; \
+ done; \
+ dot_seen=no; \
+ target=`echo $@ | sed s/-recursive//`; \
+ list='$(SUBDIRS)'; for subdir in $$list; do \
+ echo "Making $$target in $$subdir"; \
+ if test "$$subdir" = "."; then \
+ dot_seen=yes; \
+ local_target="$$target-am"; \
+ else \
+ local_target="$$target"; \
+ fi; \
+ (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
+ || eval $$failcom; \
+ done; \
+ if test "$$dot_seen" = "no"; then \
+ $(MAKE) $(AM_MAKEFLAGS) "$$target-am" || exit 1; \
+ fi; test -z "$$fail"
+
+mostlyclean-recursive clean-recursive distclean-recursive \
+maintainer-clean-recursive:
+ @failcom='exit 1'; \
+ for f in x $$MAKEFLAGS; do \
+ case $$f in \
+ *=* | --[!k]*);; \
+ *k*) failcom='fail=yes';; \
+ esac; \
+ done; \
+ dot_seen=no; \
+ case "$@" in \
+ distclean-* | maintainer-clean-*) list='$(DIST_SUBDIRS)' ;; \
+ *) list='$(SUBDIRS)' ;; \
+ esac; \
+ rev=''; for subdir in $$list; do \
+ if test "$$subdir" = "."; then :; else \
+ rev="$$subdir $$rev"; \
+ fi; \
+ done; \
+ rev="$$rev ."; \
+ target=`echo $@ | sed s/-recursive//`; \
+ for subdir in $$rev; do \
+ echo "Making $$target in $$subdir"; \
+ if test "$$subdir" = "."; then \
+ local_target="$$target-am"; \
+ else \
+ local_target="$$target"; \
+ fi; \
+ (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) $$local_target) \
+ || eval $$failcom; \
+ done && test -z "$$fail"
+tags-recursive:
+ list='$(SUBDIRS)'; for subdir in $$list; do \
+ test "$$subdir" = . || (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) tags); \
+ done
+ctags-recursive:
+ list='$(SUBDIRS)'; for subdir in $$list; do \
+ test "$$subdir" = . || (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) ctags); \
+ done
+
+ID: $(HEADERS) $(SOURCES) $(LISP) $(TAGS_FILES)
+ list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
+ unique=`for i in $$list; do \
+ if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
+ done | \
+ $(AWK) ' { files[$$0] = 1; } \
+ END { for (i in files) print i; }'`; \
+ mkid -fID $$unique
+tags: TAGS
+
+TAGS: tags-recursive $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \
+ $(TAGS_FILES) $(LISP)
+ tags=; \
+ here=`pwd`; \
+ if ($(ETAGS) --etags-include --version) >/dev/null 2>&1; then \
+ include_option=--etags-include; \
+ empty_fix=.; \
+ else \
+ include_option=--include; \
+ empty_fix=; \
+ fi; \
+ list='$(SUBDIRS)'; for subdir in $$list; do \
+ if test "$$subdir" = .; then :; else \
+ test ! -f $$subdir/TAGS || \
+ tags="$$tags $$include_option=$$here/$$subdir/TAGS"; \
+ fi; \
+ done; \
+ list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
+ unique=`for i in $$list; do \
+ if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
+ done | \
+ $(AWK) ' { files[$$0] = 1; } \
+ END { for (i in files) print i; }'`; \
+ if test -z "$(ETAGS_ARGS)$$tags$$unique"; then :; else \
+ test -n "$$unique" || unique=$$empty_fix; \
+ $(ETAGS) $(ETAGSFLAGS) $(AM_ETAGSFLAGS) $(ETAGS_ARGS) \
+ $$tags $$unique; \
+ fi
+ctags: CTAGS
+CTAGS: ctags-recursive $(HEADERS) $(SOURCES) $(TAGS_DEPENDENCIES) \
+ $(TAGS_FILES) $(LISP)
+ tags=; \
+ here=`pwd`; \
+ list='$(SOURCES) $(HEADERS) $(LISP) $(TAGS_FILES)'; \
+ unique=`for i in $$list; do \
+ if test -f "$$i"; then echo $$i; else echo $(srcdir)/$$i; fi; \
+ done | \
+ $(AWK) ' { files[$$0] = 1; } \
+ END { for (i in files) print i; }'`; \
+ test -z "$(CTAGS_ARGS)$$tags$$unique" \
+ || $(CTAGS) $(CTAGSFLAGS) $(AM_CTAGSFLAGS) $(CTAGS_ARGS) \
+ $$tags $$unique
+
+GTAGS:
+ here=`$(am__cd) $(top_builddir) && pwd` \
+ && cd $(top_srcdir) \
+ && gtags -i $(GTAGS_ARGS) $$here
+
+distclean-tags:
+ -rm -f TAGS ID GTAGS GRTAGS GSYMS GPATH tags
+check-am: all-am
+check: check-recursive
+all-am: Makefile $(DATA)
+installdirs: installdirs-recursive
+installdirs-am:
+ for dir in "$(DESTDIR)$(docdir)"; do \
+ test -z "$$dir" || $(mkdir_p) "$$dir"; \
+ done
+install: install-recursive
+install-exec: install-exec-recursive
+install-data: install-data-recursive
+uninstall: uninstall-recursive
+
+install-am: all-am
+ @$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
+
+installcheck: installcheck-recursive
+install-strip:
+ $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
+ install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
+ `test -z '$(STRIP)' || \
+ echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
+mostlyclean-generic:
+
+clean-generic:
+
+distclean-generic:
+ -test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
+
+maintainer-clean-generic:
+ @echo "This command is intended for maintainers to use"
+ @echo "it deletes files that may require special tools to rebuild."
+clean: clean-recursive
+
+clean-am: clean-generic mostlyclean-am
+
+distclean: distclean-recursive
+ -rm -f Makefile
+distclean-am: clean-am distclean-generic distclean-tags
+
+dvi: dvi-recursive
+
+dvi-am:
+
+html: html-recursive
+
+info: info-recursive
+
+info-am:
+
+install-data-am: install-docDATA
+
+install-exec-am:
+
+install-info: install-info-recursive
+
+install-man:
+
+installcheck-am:
+
+maintainer-clean: maintainer-clean-recursive
+ -rm -f Makefile
+maintainer-clean-am: distclean-am maintainer-clean-generic
+
+mostlyclean: mostlyclean-recursive
+
+mostlyclean-am: mostlyclean-generic
+
+pdf: pdf-recursive
+
+pdf-am:
+
+ps: ps-recursive
+
+ps-am:
+
+uninstall-am: uninstall-docDATA uninstall-info-am
+
+uninstall-info: uninstall-info-recursive
+
+.PHONY: $(RECURSIVE_TARGETS) CTAGS GTAGS all all-am check check-am \
+ clean clean-generic clean-recursive ctags ctags-recursive \
+ distclean distclean-generic distclean-recursive distclean-tags \
+ dvi dvi-am html html-am info info-am install install-am \
+ install-data install-data-am install-docDATA install-exec \
+ install-exec-am install-info install-info-am install-man \
+ install-strip installcheck installcheck-am installdirs \
+ installdirs-am maintainer-clean maintainer-clean-generic \
+ maintainer-clean-recursive mostlyclean mostlyclean-generic \
+ mostlyclean-recursive pdf pdf-am ps ps-am tags tags-recursive \
+ uninstall uninstall-am uninstall-docDATA uninstall-info-am
+
+# Tell versions [3.59,3.63) of GNU make to not export all variables.
+# Otherwise a system limit (for SysV at least) may be exceeded.
+.NOEXPORT:
diff --git a/Build/source/utils/xindy/doc/README b/Build/source/utils/xindy/doc/README
new file mode 100644
index 00000000000..90440f93683
--- /dev/null
+++ b/Build/source/utils/xindy/doc/README
@@ -0,0 +1,14 @@
+$Id: README.distrib,v 1.3 2008/01/09 11:11:46 jschrod Exp $
+------------------------------------------------------------
+
+This directory contains documentation of `xindy'.
+
+Manual pages for the commands are created during installation and are
+placed in appropriate man directories.
+PDF versions of the manual pages have been added here for your convenience.
+
+The subdirectory ./style-tutorial/ contains the examples that are used
+in the xindy style tutorial.
+
+FAQ and style tutorial are out of date. (Updates are welcome, of course.)
+You find more documentation at the xindy Web Site, at http://www.xindy.org/.
diff --git a/Build/source/utils/xindy/doc/dataflow.gif b/Build/source/utils/xindy/doc/dataflow.gif
new file mode 100644
index 00000000000..203b5521ba6
--- /dev/null
+++ b/Build/source/utils/xindy/doc/dataflow.gif
Binary files differ
diff --git a/Build/source/utils/xindy/doc/faq-1.html b/Build/source/utils/xindy/doc/faq-1.html
new file mode 100644
index 00000000000..31fcfba7abd
--- /dev/null
+++ b/Build/source/utils/xindy/doc/faq-1.html
@@ -0,0 +1,169 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <TITLE>XINDY FAQ: General Questions</TITLE>
+ <LINK HREF="faq-2.html" REL=next>
+
+ <LINK HREF="faq.html#toc1" REL=contents>
+</HEAD>
+<BODY>
+<A HREF="faq-2.html">Next</A>
+Previous
+<A HREF="faq.html#toc1">Contents</A>
+<HR>
+<H2><A NAME="s1">1. General Questions</A></H2>
+
+<H2><A NAME="ss1.1">1.1 Why a completely new indexing tool? <CODE>makeindex</CODE> works fine!</A>
+</H2>
+
+<P>
+<P>With the <EM>International MakeIndex</EM> project, Joachim Schrod and
+Gabor Herr have shown that adding extensions to
+<CODE>makeindex</CODE> is a difficult job. Thus we have decided to develop a
+new indexing tool from scratch. The new tool is based on a new
+requirements analysis and offers very interesting features for
+processing very complex indexing schemes. The resulting index model is
+described in:
+<P>
+<OL>
+<LI> Roger Kehr, <SF>xindy</SF> -- <EM>A Flexible Indexing System</EM>,
+Proceedings of the EuroTeX'98, St. Malo, France, March 1998
+</LI>
+<LI> Roger Kehr, <SF>xindy</SF> -- <EM>A Flexible Indexing System</EM>,
+Technical Report No. 11/1997, Computer Science Department, Darmstadt
+University of Technology, 1997. Also accessible from the xindy
+homepage.
+</LI>
+<LI> Roger Kehr, xindy <EM>Ein Flexibles Indexierungssystem</EM>,
+Studienarbeit FB Informatik, TH-Darmstadt, November 1995.
+</LI>
+<LI> Joachim Schrod, <EM>An International Version of MakeIndex</EM>,
+Cahiers GUTenberg, 10, p81-90, 1991
+</LI>
+<LI> Joachim Schrod and Gabor Herr, <EM>MakeIndex Version 3.0</EM>,
+Technical University of Darmstadt, 1991
+</LI>
+</OL>
+<P>
+<P>
+<P>
+<H2><A NAME="ss1.2">1.2 I'm an old <CODE>makeindex</CODE> wizard. What does <SF>xindy</SF> offer that <CODE>makeindex</CODE> doesn't?</A>
+</H2>
+
+<P>
+<P>Here are the most important differences between <SF>xindy</SF> and
+<CODE>makeindex</CODE>:
+<P>
+<P>
+<DL>
+<P>
+<DT><B>Internationalization</B><DD><P><SF>xindy</SF> can be configured to process
+indexes for many languages with different letter sets and different
+sorting rules. For example, many roman languages such as Italian,
+French, Portuguese or Spanish contain accentuated letters such as
+&Agrave;, &Aacute;, &ntilde;. Other languages from northern Europe
+have letters like &Auml;, &Oslash;, &aelig; or &szlig; which often
+can't be processed by many index processors not talking about sorting
+them correctly into an index. The <SF>xindy</SF>-system can be configured
+to process these alphabets by defining <EM>sort</EM> and
+<EM>merge-rules</EM> that allow expressing of language specific rules.
+One example of such a rule would be
+<P>
+<PRE>
+(sort-rule &quot;ä&quot; &quot;ae&quot;)
+</PRE>
+<P>defining that a word containing the umlaut-a will be sorted as if it
+contained the letters <CODE>ae</CODE> instead. This is one form of how the
+umlaut-a is sorted into german indexes. With an appropriate set of
+rules one can express the complete rules of a specific language.
+<P>
+<DT><B>Location classes.</B><DD><P><CODE>makeindex</CODE> is able to recognize and
+process arabic numbers, roman numerals and letter-based alphabets as
+specifiers for the indexed location. Simple composite structures of
+these are also possible to process. This implicit recognition scheme
+has completely been dropped in favour of a well-defined and very
+powerful declaration scheme called <EM>location-classes</EM>. Thus,
+<SF>xindy</SF> initally does not know any location-class by default and
+must be instructed to accept certain location-classes. A typical
+declaration might look like:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(define-location-class "page-numbers" ("arabic-numbers"))
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This declares that page numbers consist of the enumeration of the
+arabic numbers. The arabic numbers are referred to as <EM>alphabets</EM>.
+Users may use the pre-defined alphabets arabic numbers, roman
+numerals, etc. or define new alphabets as needed. See the tutorial
+that comes with this distribution for some examples.
+<P>
+<DT><B>The concept of attributes.</B><DD><P>With <CODE>makeindex</CODE> one can assign a
+markup to each index entry using the encapsulators (usually following
+the vertical bar sign in an index entry command). For example in the
+specification
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+\index{xindy|bold}
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>the encapsulator is <CODE>bold</CODE> which encapsulates the page-numbers in
+the markup-phase. An additional TeX-macro must be supplied to assign
+some markup with the page number. This concept has completely been
+dropped in <SF>xindy</SF> in favour of a more powerful scheme called
+<EM>attributes</EM>. Attributes can be used to (i) define several grouping
+and ordering rules with locations and we can define (ii) markup-tags
+for the document preparation system.
+<P>The result of this design decision is that the user is required to
+define the attributes in the style file and not in the document
+preparation system. The reasons lie in the more powerful markup scheme
+of <SF>xindy</SF> which can't be specified in the document processor anymore.
+In fact, the <CODE>makeindex</CODE>-like markup is only a small subset of
+<SF>xindy</SF>s features.
+<P>
+<DT><B>Cross references.</B><DD><P>Cross-references were implemented in
+<CODE>makeindex</CODE> with the encapsulation mechanism, which only served for
+markup purposes. This has been completely separated in <SF>xindy</SF>.
+Here we distinguish cleanly between attributes and cross references.
+This makes it possible to implement <EM>checked</EM> cross references,
+i.e. cross-refernces that can be checked if they point to an existing
+index entry instead of somewhere ``behind-the-moon''.
+<P>
+<DT><B>Less command-line options.</B><DD><P><SF>xindy</SF> has dropped the usage of
+command-line options in favour of a well-defined indexstyle
+description language. Thus, options that could be activated at the
+command-line level of <CODE>makeindex</CODE> must now be specified in the
+indexstyle file. This sounds more restrictive than it is, because the
+indexstyle files can be composed from several modules which makes it
+possible to write style files in just a few lines of code.
+<P>
+<DT><B>Raw index parser.</B><DD><P>The parser built into <CODE>makeindex</CODE> has
+completely been separated from the core <SF>xindy</SF> system. <SF>xindy</SF>
+understands a well-defined specification language for the raw index
+that is completely different from <CODE>makeindex</CODE>, but in our opinion
+more maintainable than the <CODE>makeindex</CODE> format. This requires a
+separate filter that transforms arbitrary indexes to the <SF>xindy</SF>
+format. An example filter is the program <CODE>tex2xindy</CODE> that comes
+with this distribution.
+<P>
+</DL>
+<P>Summed up, some of the implicit assumptions made by <CODE>makeindex</CODE>
+have been replaced and now burdend to the user. The reason is that
+many of <CODE>makeindex</CODE>'s assumptions were no longer valid in
+multi-language environments or documents with arbitrary location
+structures. This also characterizes <SF>xindy</SF> more as a framework
+instead of a end-user-tailored product. One should notice that writing
+an appropriate index style is an essential part of the document
+preparation process and should be tailored to each document anew.
+<P>
+<P>
+<P>
+<P>
+<HR>
+<A HREF="faq-2.html">Next</A>
+Previous
+<A HREF="faq.html#toc1">Contents</A>
+</BODY>
+</HTML>
diff --git a/Build/source/utils/xindy/doc/faq-2.html b/Build/source/utils/xindy/doc/faq-2.html
new file mode 100644
index 00000000000..00be36138dc
--- /dev/null
+++ b/Build/source/utils/xindy/doc/faq-2.html
@@ -0,0 +1,95 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <TITLE>XINDY FAQ: xindy Usage</TITLE>
+ <LINK HREF="faq-3.html" REL=next>
+ <LINK HREF="faq-1.html" REL=previous>
+ <LINK HREF="faq.html#toc2" REL=contents>
+</HEAD>
+<BODY>
+<A HREF="faq-3.html">Next</A>
+<A HREF="faq-1.html">Previous</A>
+<A HREF="faq.html#toc2">Contents</A>
+<HR>
+<H2><A NAME="s2">2. <SF>xindy</SF> Usage</A></H2>
+
+<H2><A NAME="ss2.1">2.1 I don't want to write style files. How can I proceed?</A>
+</H2>
+
+<P>
+<P>You can use the wrapper program <CODE>makeindex4</CODE>. It tries to do it's
+very best to make <SF>xindy</SF> behave as <CODE>makeindex</CODE> does. But if you
+ever need to use some of the features of <SF>xindy</SF> you should learn
+how to write an index style. Its easy!
+<P>
+<P>
+<P>
+<H2><A NAME="ss2.2">2.2 How do I use <CODE>makeindex4</CODE>?</A>
+</H2>
+
+<P>
+<P>Process your document as usual. Then run <CODE>makeindex4</CODE> on the index
+file. It produces an index that should equal the one you would get
+with an ordinary <CODE>makeindex</CODE> run. As far as you are satisfied with
+the default behaviour of <CODE>makeindex</CODE>, <CODE>makeindex4</CODE> will produce
+comparable results.
+<P>Some of the command-line options of <CODE>makeindex</CODE> are accepted by
+<CODE>makeindex4</CODE>, others aren't. This may change in future releases,
+but we recommend using plain <SF>xindy</SF> after a phase of
+investigation, since one cannot use all of its features with
+<CODE>makeindex4</CODE>. You will be informed about unsupported command-line
+arguments when running <CODE>makeindex4</CODE>.
+<P>If you have written special style files for <CODE>makeindex</CODE> they will
+no longer work with <CODE>makeindex4</CODE>. Go ahead and write a new style
+file for <SF>xindy</SF>.
+<P>
+<P>
+<P>
+<H2><A NAME="ss2.3">2.3 How works <CODE>makeindex4</CODE>?</A>
+</H2>
+
+<P>
+<P>This job is now done automatically by <CODE>makeindex4</CODE>. It calls
+<CODE>tex2xindy</CODE> to transform the raw-index into the format suitable for
+<SF>xindy</SF>. <CODE>tex2xindy</CODE> emits some information about the attributes
+(aka. encapsulators in <CODE>makeindex</CODE>) and the usage of
+cross-references into a file, which has the extension `<CODE>.sta</CODE>'. The
+<CODE>makeindex4</CODE> program, written in <CODE>perl</CODE>, parses this
+statistics-file and generates the above presented indexstyle commands
+for you automatically including the required declaration of all
+attributes in the whole index and their markup.
+<P>Another problem is the automatic detection of cross-references. As
+noted above, <CODE>makeindex</CODE> handles cross-references with its
+encapsulation mechanism, a scheme which has been dropped in <SF>xindy</SF>
+and replaced by a more powerful mechanism. To implement a simple
+plug-in mechanism we have extended the syntax of the <CODE>tex2xindy</CODE>
+filter to identify encapsulators of the form
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+\indexentry{...|encap{...}}{...}
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>as a cross-reference, whereas encapsulators of the form
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+\indexentry{...|encap}{...}
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>are treated as ordinary attributes. This is standard practice
+defining cross-references in <CODE>makeindex</CODE>. Thus, <CODE>tex2xindy</CODE>
+distinguishes these two forms of encapsulators as opposed to
+<CODE>makeindex</CODE> and our plug-in <CODE>makeindex4</CODE> generates the
+appropriate definitions of the cross-reference classes as well.
+<P>
+<P>
+<P>
+<P>
+<HR>
+<A HREF="faq-3.html">Next</A>
+<A HREF="faq-1.html">Previous</A>
+<A HREF="faq.html#toc2">Contents</A>
+</BODY>
+</HTML>
diff --git a/Build/source/utils/xindy/doc/faq-3.html b/Build/source/utils/xindy/doc/faq-3.html
new file mode 100644
index 00000000000..12895e8cb29
--- /dev/null
+++ b/Build/source/utils/xindy/doc/faq-3.html
@@ -0,0 +1,83 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <TITLE>XINDY FAQ: xindy and LaTeX</TITLE>
+ <LINK HREF="faq-4.html" REL=next>
+ <LINK HREF="faq-2.html" REL=previous>
+ <LINK HREF="faq.html#toc3" REL=contents>
+</HEAD>
+<BODY>
+<A HREF="faq-4.html">Next</A>
+<A HREF="faq-2.html">Previous</A>
+<A HREF="faq.html#toc3">Contents</A>
+<HR>
+<H2><A NAME="s3">3. <SF>xindy</SF> and LaTeX</A></H2>
+
+<H2><A NAME="ss3.1">3.1 What is <CODE>tex2xindy</CODE>?</A>
+</H2>
+
+<P>
+<P><CODE>tex2xindy</CODE> is a filter that parses `<CODE>.idx</CODE>' or similar files
+and converts the <CODE>\indexentry</CODE> macros into a form readable by
+<SF>xindy</SF>.
+<P>The parser of <CODE>makeindex</CODE> can be configured to recognize different
+quoting characters, etc. (see the man-page for <CODE>makeindex</CODE>, section
+<EM>input style specifiers</EM> for further details). We have tried to
+extract the parser from <CODE>makeindex</CODE> but due to several probems we
+have finally rewritten the parser using <CODE>lex</CODE>. Scanners written
+with <CODE>lex</CODE> are usually fixed to a specific character set used in
+the regular expressions. Our parser, <CODE>tex2xindy</CODE> is therefore not
+configurable. If one uses a different configuration of the
+<CODE>makeindex</CODE> input style specifiers, one can change the source
+(<CODE>tex2xindy.l</CODE>) to generate a completely new parser. From our
+personal experience we have rarely used more than two different
+parsers in practice so we have written <CODE>tex2xindy</CODE> in a form that
+is easily maintainable. The input specifiers are stored symbolically
+in the source. The definiton section looks like this:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+KEYWORD \\indexentry
+ENCAP \|
+ACTUAL @
+ESCAPE \\
+LEVEL !
+QUOTE \"
+ROPEN \(
+RCLOSE \)
+ARGOPEN \{
+ARGCLOSE \}
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>These definitions are essentially the input style specifiers as can be
+found in the man-page of <CODE>makeindex</CODE>. Changing this section
+according to your needs and recompiling <CODE>tex2xindy</CODE> should be an
+easy task. Maybe we will include more pre-defined parsers in future
+releases if necessary.
+<P>
+<P>
+<P>
+<H2><A NAME="ss3.2">3.2 What LaTeX-package should I use in conjunction with xindy?</A>
+</H2>
+
+<P>
+<P>We strongly recommend using the LaTeX2e-package <CODE>index</CODE> written
+by David M. Jones, which is available at CTAN. It supports multiple
+indexes as well as several shortcuts to easily index terms in a
+document. Multiple indexes support the generation of several indexes
+for one document. For instance, one can make an author or command
+index in addition to a global index.
+<P>Another option is to use the <CODE>xindy.sty</CODE> from Andreas Schlechte
+that comes with the <SF>xindy</SF> distribution. Take a look at the
+<CODE>contrib</CODE> directory that should contain a version.
+<P>
+<P>
+<P>
+<P>
+<HR>
+<A HREF="faq-4.html">Next</A>
+<A HREF="faq-2.html">Previous</A>
+<A HREF="faq.html#toc3">Contents</A>
+</BODY>
+</HTML>
diff --git a/Build/source/utils/xindy/doc/faq-4.html b/Build/source/utils/xindy/doc/faq-4.html
new file mode 100644
index 00000000000..81052562f1d
--- /dev/null
+++ b/Build/source/utils/xindy/doc/faq-4.html
@@ -0,0 +1,668 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <TITLE>XINDY FAQ: Style Files</TITLE>
+ <LINK HREF="faq-3.html" REL=previous>
+ <LINK HREF="faq.html#toc4" REL=contents>
+</HEAD>
+<BODY>
+Next
+<A HREF="faq-3.html">Previous</A>
+<A HREF="faq.html#toc4">Contents</A>
+<HR>
+<H2><A NAME="s4">4. Style Files</A></H2>
+
+<H2><A NAME="ss4.1">4.1 Eventually, I decided to write my first index style. How can I start?</A>
+</H2>
+
+<P>
+<P>Congratulations! You have made a good decision, indeed.
+<P>For a first impression, how a style file can be written from scratch
+reference the <EM>tutorial</EM> that comes with this distribution. It is
+written as a guided step-by-step practicing exercise and you can learn
+the basic concepts quite easily.
+<P>Afterwards, the best starting point is to make a copy of the template
+file that contains all the necessary commands that are needed to make
+a <CODE>makeindex</CODE>-like index. You can find it in the subdirectory
+<CODE>markup/tex</CODE> of the module library. Starting from this template
+you can remove or add commands as necessary.
+<P>Additionally, consult the library of predefined <EM>index style
+modules</EM> that comes with this distribution. Solutions for most of the
+typical problems can be found there, such as a module for doing
+case-insensitive sorting rules, or a typical TeX-like markup. Most
+of the time is is enough to include some of these modules and add a
+few additional commands.
+<P>Maybe some of the examples coming with the <EM>test-suite</EM> are good
+examples of how unusual index style files can be written.
+<P>Thus, there are many ways to learn writing an index style file. But it
+is very easy and after some experience you can process indexes your
+friends will be jealous of.
+<P>
+<P>
+<H2><A NAME="ss4.2">4.2 How to write my first index style?</A>
+</H2>
+
+<P>
+<P>Copy the file <CODE>tex/makeidx.xdy</CODE> from the library to your
+local directory. It is documented in in a way that should make it easy
+to fill in new commands or remove or modify others.
+<P>
+<P>
+<P>
+<H2><A NAME="ss4.3">4.3 How works the actual key feature of <CODE>makeindex</CODE> with <SF>xindy</SF>?</A>
+</H2>
+
+<P>
+<P>The treatment of the actual key (usually denoted with <CODE>@</CODE>, the
+at-sign) has changed with <SF>xindy</SF>. Specifying index entries with a
+specific markup can be done in <CODE>makeindex</CODE> with the actual key. The
+<CODE>makeindex-3</CODE> system and <SF>xindy</SF> offer the <EM>merge-</EM> and
+<EM>sort-rules</EM> to transform a key into different representations,
+limiting the need to specify an actual key. For example they support a
+style of writing
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+\index{\bf{VIP}}
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>which can be transformed with a rule like
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(merge-rule "\bf{\(.*\)}" "\1" :again :bregexp)
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>which removes the macro definition for merging and sorting keywords,
+but keeping the original definition for markup purposes. Therefore we
+don't need any actual keys for all keywords written in boldface.
+<P>The <CODE>makeindex</CODE> behaviour, that the two keywords
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+\index{VIP}
+\index{VIP@\bf{VIP}}
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>are seen as two distinct index entries, can be simulated using the
+following definition:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(merge-rule "\bf{\(.*\)}" "\1~e" :again :bregexp)
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This rule tells <SF>xindy</SF> to remove the boldface macro for merging
+and sorting purposes but defines the replacement to include the
+special character <CODE>~e</CODE>, which is the last character in the
+alphabet (ISO-Latin in our case). This makes <SF>xindy</SF> treat them as
+different keywords and positions the boldface keyword right behind the
+one without any markup. Thus we receive the following mapping:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+Keyword: Merged and sorted as: Appears in the index as:
+VIP VIP VIP
+\bf{VIP} VIP~e \bf{VIP}
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>With this new style of writing keywords and defining their markup, the
+need to explicitly specifying the print key (aka. actual key) has
+convinced us to remove the <CODE>makeindex</CODE> way of defining keywords.
+<P>
+<P>
+<P>
+<H2><A NAME="ss4.4">4.4 I want to process an index for my native language. What must I do?</A>
+</H2>
+
+<P>
+<P>What makes <CODE>makeindex</CODE> hardly usable in non-English speaking
+countries is its lack of support of language specific alphabets and
+sort orderings. For example, many roman languages such as Italian,
+French, Portuguese or Spanish contain accented letters such as
+&Agrave;, &Aacute;, &ntilde;. Other languages from northern Europe
+have letters like &Auml;, &Oslash;, &aelig; or &szlig; which often
+can't even be processed by many index processors let alone sorting
+them correctly into an index.
+<P>Two problems must be solved when processing indexes with a new
+languages:
+<P>
+<OL>
+<LI> The <EM>sort ordering</EM> of the indexed terms must be specified
+in an appropriate manner. This problem can be solved using the
+so-called <EM>keyword mappings</EM>.
+</LI>
+<LI> The <EM>letter groups</EM> that partition the indexed terms into
+separate sections must be specified.</LI>
+</OL>
+<P>The <SF>xindy</SF> system can be configured to process these alphabets by
+defining <EM>sort</EM> and <EM>merge rules</EM> that allow expressing language
+specific rules.
+<P>The keyword mappings are as follows: The <EM>merge key</EM> is generated
+from the <EM>main key</EM> with the so called <EM>merge mapping</EM>. The
+merge mapping can be specified with the command <CODE>merge-rule</CODE>. The
+<EM>sort key</EM> is derived from the merge key using the <EM>sort
+mapping</EM> specified with the <CODE>sort-rule</CODE> command. The following
+scheme shows this mapping process:
+<P>
+<FIGURE>
+<EPS FILE="mappings.eps">
+<IMG SRC="mappings.gif">
+</FIGURE>
+<P>
+<P>The index style commands accomplishing this task are
+<CODE>sort-rule</CODE> and <CODE>merge-rule</CODE>. One example of such a rule would
+be
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(sort-rule "ä" "ae")
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>defining that a word containing the umlaut-a will be sorted as if it
+contained the letters <CODE>ae</CODE> instead. This is one form of how the
+umlaut-a (ä) is sorted into german indexes. With an appropriate set of
+rules on can express the complete rules of a specific language.
+<P>An example of how an appropriate mapping for some of the Roman
+languages could look like is:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(sort-rule "à" "a")
+(sort-rule "á" "a")
+(sort-rule "ã" "a")
+(sort-rule "è" "e")
+(sort-rule "é" "e")
+(sort-rule "ç" "c")
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This makes the accented letters be sorted as their unaccented
+counterparts, yielding the desired sort ordering.
+<P>Sometimes it is necessary to specify keyword mappings that tell the
+system to put something <EM>behind</EM> something else. For instance, we'd
+like to map the character <EM>ö</EM> behind the letter <EM>o</EM>. No problem
+if you use the special characters <CODE>~b</CODE> and <CODE>~e</CODE> which
+are called the <EM>beginning</EM> and <EM>ending</EM> characters. The first
+letter lexicographically precedes all other letters whereas the latter
+one comes after all others. Our mapping problem can now be specified
+as follows.
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(sort-rule "ö" "o~e")
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Now the <EM>ö</EM> is directly positioned after the <EM>o</EM> but before
+<EM>p</EM>.
+<P>
+<P>See the manual for a detailed description of this feature.
+Also be informed that the keyword mappings can be specified with
+regular expressions. Rules of the form
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(merge-rule "[-$()]" "")
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>are possible. This on removes all letters of the defined letter class.
+Regular expression substitutions are possible as well. Refer to the
+manual for an exact description.
+<P>
+<P>
+<P>
+<H2><A NAME="ss4.5">4.5 In my index the capitalized words appear after the lowercase words. Why?</A>
+</H2>
+
+<P>
+<P>The default sort ordering sorts letters according to their ordinal
+number in the ISO Latin alphabet. As a consequence the lowercase
+letters appear before the uppercase letters. To sort them
+case-insensitively use the command
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(require "lang/latin/caseisrt.xdy")
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This module defines the appropriate sort rules for the letters `A-Z'
+for latin-based alphabets. If your language has more letters simply
+add the missing ones into your style file. Have a look at the module
+to see how to the sort rules are defined.
+<P>
+<P>
+<P>
+<H2><A NAME="ss4.6">4.6 In my index there are no letter groups, yet!</A>
+</H2>
+
+<P>
+<P>Letter groups for latin based alphabets can be defined with the command
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(require "lang/latin/letgroup.xdy")
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>If your language needs additional letter groups you can insert them
+into the previously defined letter group with inserting definitions of
+the following form:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(define-letter-group "ly" :after "l" :before "m")
+(define-letter-group "ny" :after "n" :before "o")
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This adds two more letter groups to the latin alphabet. Group <EM>ly</EM>
+is inserted between <EM>l</EM> and <EM>m</EM>, and <EM>ny</EM> is inserted between
+<EM>n</EM> and <EM>o</EM>. This is how two additional letters of the Hungarian
+alphabet can be inserted.
+<P>
+<P>
+<P>
+<H2><A NAME="ss4.7">4.7 How can I get rid of any formatting information in the keyword?</A>
+</H2>
+
+<P>
+<P>Assume you have index entries containing arbitrary formatting
+information. For example you write your index entries in TeX in the
+following form:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+\index{\bf{In boldface please}}
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>To avoid specifying for each index entry the print key separately as
+can be done with the following command
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+\index{In boldface please@\bf{In boldface please}}
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>you can instead define a rule doing this task for you:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(merge-rule "\\bf *{(.*)}" "\1" :eregexp :again)
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This extended regular expression matches all strings that are
+surrounded by this formatting command and in the <EM>merge phase</EM> the
+formatting command is simply stripped off. Thus, you don't need to
+write an explicit print key anymore.
+<P>If for some reason the same word appears more than once in the index,
+each time having another markup tag as in the following example
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+index
+{\tt index}
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>you must be warned that a rule like
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(merge-rule "{\\tt *(.*)}" "\1" :eregexp :again)
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>is probably not correct. In this case the above strings are both
+mapped into the string <CODE>index</CODE> thus joining their location
+references into one index entry. This happens because the result of
+the merge mapping is used as the equality citerium which views both
+keywords as equal. To avoid this you should specify instead
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(merge-rule "{\\tt *(.*)}" "\1~e" :eregexp :again)
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>With the additional meta character <CODE>~e</CODE> the substitution of the
+second key word is placed <EM>after</EM> the first one making them
+different index entries. If the second keyword should appear first,
+use <CODE>~b</CODE> instead.
+<P>
+<P>
+<P>
+<P>
+<H2><A NAME="ss4.8">4.8 In my index the word <EM>-foo</EM> appears before <EM>bar</EM>. What must I do?</A>
+</H2>
+
+<P>
+<P>Especially for hierarchical indexes sometimes the result is not as
+expected due to special characters appearing in the keyword. In the
+following example the word `card' should appear before `-eyed' since
+the hyphen should not count as an ordinary character by means of
+sorting.
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+ green
+ -eyed 12
+ card 15
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This is especially problematic if the list of words on the second
+level is very long. To make the hyphen be simply ignored during the
+sorting process you should specify the following command in the index
+style:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+ (sort-rule "-" "")
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This makes `-eyed' be sorted as `eyed' thus making it appear
+<EM>after</EM> `card' as desired.
+<P>
+<P>
+<P>
+<P>
+<H2><A NAME="ss4.9">4.9 I want to use letter ordering instead of word ordering in my index.</A>
+</H2>
+
+<P>
+<P>According to the <EM>Chicago Manual of Style</EM> there exist two
+different schemes of sorting word lists. In <EM>word ordering</EM>
+a blank precedes any letter in the alphabet, whereas in <EM>letter
+ordering</EM> it does not count at all. The following example borrowed
+from the <CODE>makeindex</CODE> man-page illustrates the difference:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+ Word Order: Letter Order:
+ sea lion seal
+ seal sea lion
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>By default, <SF>xindy</SF> uses word ordering. To use letter ordering
+include the appropriate module with the following command:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(require "ord/letorder.xdy")
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>It actually defines the following command:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(sort-rule " " "")
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This simply removes all blanks from the keyword resulting in the
+desired behaviour.
+<P>
+<P>
+<P>
+<P>
+<H2><A NAME="ss4.10">4.10 My document does not have page numbers, but a different scheme. What must I do?</A>
+</H2>
+
+<P>
+<P>The ability to deal with user-definable location structures is one of
+the most important new features of <SF>xindy</SF>. Many documents have a
+document structure that is not based on page numbers. Typical examples
+are manuals or appendices that come with a
+<EM>chapter/page-per-chapter</EM> numbering scheme, URLs, Bible verses,
+etc. One can even imagine the Greek alphabet as possibly appearing in
+a location reference. In our analysis we have found many interesting
+examples of location references that made us to develop the concept of
+<EM>location classes</EM>.
+<P>A location class is defined by a sequence of alphabets. An alphabet
+can be the set of arabic numbers (0, 1, 2, ...) or the roman numerals
+(i, ii, iii, ...). These are built-in alphabets in <SF>xindy</SF>.
+Addtionally, one can define more alphabets in the index style with a
+command like
+<P>
+<PRE>
+ (define-alphabet "weekdays"
+ ("mon" "tue" "wed" "thu" "fri" "sat" "sun"))
+</PRE>
+<P>Based on alphabets one can now compose a location class as follows:
+<P>
+<PRE>
+ (define-location-class "weekday-hours"
+ ("weekday" :sep ":" "arabic-numbers"))
+</PRE>
+<P>This class description indicates that all location refernces matching
+this template are viewed as correct instances of this class. Here
+<CODE>:sep</CODE> makes the dot serving as a <EM>separation string</EM> separation
+the alphabets from each other. Example instances of this class are:
+<P>
+<PRE>
+mon:23, thu:45, sun:17
+</PRE>
+<P>For more detailed information consult the description of the command
+<CODE>define-location-class</CODE> in the reference manual.
+<P>
+<P>
+<P>
+<H2><A NAME="ss4.11">4.11 I don't want to have ranges in my index. What can I do?</A>
+</H2>
+
+<P>
+<P>By default, <SF>xindy</SF> joins three successive location references into a
+<EM>range</EM>. Ranges are used as an abbrevation for a long sequence of
+location references. For exmaple the sequence
+<P>
+<PRE>
+12, 13, 14, 15, 16
+</PRE>
+<P>would be shorter represented as
+<P>
+<PRE>
+12-16
+</PRE>
+<P>If you don't want to have ranges, simply define your location class in
+the form
+<P>
+<PRE>
+ (define-location-class ... :min-range-length none)
+</PRE>
+<P>The argument <CODE>:min-range-length none</CODE> avoids forming of ranges.
+Arbitrary numbers instead of <CODE>none</CODE> define the minimum length of a
+sequence of location references that are needed to form a range.
+<SF>xindy</SF>s default value is&nbsp;2.
+<P>
+<P>
+<P>
+<H2><A NAME="ss4.12">4.12 I want to markup ranges of different length differently. How do I accomplish this?</A>
+</H2>
+
+<P>
+<P>A common way of tagging ranges is as follows: a range of length 1 is
+printed with the starting page number and the suffix `f.', those of
+length 2 with suffix `ff.', and all others in the form `<EM>X--Y</EM>'.
+<P>Assume we want to do this for the location class <EM>pagenums</EM> we can
+specify the markup as follows:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(markup-range :class "pagenums" :close "f." :length 1 :ignore-end)
+(markup-range :class "pagenums" :close "ff." :length 2 :ignore-end)
+(markup-range :class "pagenums" :sep "--")
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>The first command indicates that a range <EM>(X,Y)</EM> of length 1 should
+be printed in the form <EM>Xf.</EM>, a range of length 2 as <EM>Xff.</EM> and
+all others in the form <EM>X--Y</EM>. The switch <CODE>:ignore-end</CODE> causes
+the end of range location reference Y to be suppressed in the
+resulting output.
+<P>
+<P>
+<H2><A NAME="ss4.13">4.13 I need to suppress some of the markup tags. How can I do this?</A>
+</H2>
+
+<P>Sometimes it is necessary to hide some of the parts of the index. If
+you have a text formatter that allows comments or macros that possibly
+expand to nothing, just define appropriate markup that makes things
+invisible to the formatter. For example, with TeX you can define a
+macro like this
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+\def\ignore#1{}
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>If you additionally define markup like this
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(markup-index :open "\ignore{" :close "}")
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>you can throw away the complete index if you like, which would be a
+real pity!
+<P>
+<P>
+<P>
+<H2><A NAME="ss4.14">4.14 Whats it all about those cross references?</A>
+</H2>
+
+<P>
+<P>Cross references are references pointing to an item in the index
+itself. Typical examples are:
+<P>
+<BLOCKQUOTE><CODE>
+foo-bar <EM>see</EM> baz
+</CODE></BLOCKQUOTE>
+<P>With <CODE>makeindex</CODE> cross references could be specified with the
+encapsulation mechanism. This has completely been removed in <SF>xindy</SF>
+and we have made cross references real first-class objects.
+<P>In <SF>xindy</SF> one can declare different cross reference classes, whose
+purpose is (a) to make all instances of a certain class appear next to
+each other, and (b) to specify appropriate markup with them.
+<P>@begin-comment
+One very interesting feature is the ability to <EM>check</EM> the validity
+of cross-references.
+@end-comment
+<P><CODE>tex2xindy</CODE> recognises all index entries of the form
+<P>
+<PRE>
+ \index{...|\macro{where}}
+</PRE>
+<P>as cross references. Here <CODE>macro</CODE> stands for an arbitrary macro
+name and <CODE>where</CODE> is interpreted as the target keyword of the cross
+references.
+<P>If you want to use these cross references with <SF>xindy</SF>; add the
+following line to your style file.
+<P>
+<PRE>
+ (define-crossref-class "macro")
+</PRE>
+<P>Additionally, you can assign specific markup to cross references using
+the <CODE>markup-crossref</CODE>-commands.
+<P>
+<P>
+<P>
+<H2><A NAME="ss4.15">4.15 The keyword mappings don't work as expected!</A>
+</H2>
+
+<P>
+<P>Sometimes the keyword mappings don't work as expected. Especially in
+cases with several regular expressions one might get confused about
+what rule matches exactly when. We have incorporated a detailed
+logging mechanism that lets one step by step follow the rules that
+accomplish the keyword mapping.
+<P>When running <SF>xindy</SF> you can turn on this feature with the command
+line option `<CODE>-L</CODE>'. This option followed by one of the numbers 1,
+2, or 3 turns on the appropriate debugging level. Turning on level 2
+or 3 and specifying a log-file with the command line option `<CODE>-l</CODE>'
+a trace of the mappings is recorded in the log-file. A sample output
+looks like the following:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+Mappings: (add (merge-rule :eregexp `^\\bf{(.*)}' `\1' :again)).
+Mappings: (add (merge-rule :eregexp `^\\"([AEOUaeou])' `\1')).
+ ...
+Mappings: (compare `\"A\"a' :eregexp `^\\bf{(.*)}')
+Mappings: (compare `\"A\"a' :eregexp `^\\"([AEOUaeou])') match!
+Mappings: (compare `\"a' :eregexp `^\\bf{(.*)}')
+Mappings: (compare `\"a' :eregexp `^\\"([AEOUaeou])') match!
+Mappings: (merge-mapping `\"A\"a') -> `Aa'.
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This trace shows that initially two regular expression mappings have
+been added to the rule set. The second section shows how the keyword
+`<CODE>\"A\"a</CODE>' is compared to these rules and substitutions are
+applied as matches are found. In the last line the result of the
+keyword mapping is reported.
+<P>
+<P>
+<P>
+<H2><A NAME="ss4.16">4.16 I'm totally confused by the markup scheme!</A>
+</H2>
+
+<P>
+<P>A very important feature is the ability to <EM>trace</EM> all markup tags
+<SF>xindy</SF> emits in the markup phase. Simply use the command line
+switch <CODE>-t</CODE> or insert the command
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(markup-trace :on)
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>into the index style. This informs <SF>xindy</SF> to emit additional
+pseudo markup that can be used to understand and debug the
+markup phase. An example output might look like the following:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+&lt;INDEX:OPEN>
+ &lt;LETTER-GROUP-LIST:OPEN>
+ &lt;LETTER-GROUP:OPEN ["a"]>
+ &lt;INDEXENTRY-LIST:OPEN [0]>
+ &lt;INDEXENTRY:OPEN [0]>
+ &lt;KEYWORD-LIST:OPEN [0]>
+ &lt;KEYWORD:OPEN [0]>
+ ...
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>The symbolic tags directly lead one to the command that is responsible
+for the definition of that markup tag. For example, the tag
+<CODE>LETTER-GROUP-LIST:OPEN</CODE> indicates that the command
+<CODE>markup-letter-group-list</CODE> is responsible for replacing this
+symbolic tag by a real one.
+Give it a try if you find yourself confused by your own markup
+specification.
+<P>
+<P>
+<P>
+<H2><A NAME="ss4.17">4.17 What editor should I use when writing xindy style files?</A>
+</H2>
+
+<P>
+<P>Use <CODE>Emacs</CODE> or <CODE>XEmacs</CODE>. Turn on the Lisp-mode with
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+M-x lisp-mode
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>and you can properly indent commands using <CODE>M-q</CODE>. To enter this
+mode automatically add the following lines to the end of the style
+file:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+^L
+;; Local Variables:
+;; mode: lisp
+;; End:
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>The <CODE>^L</CODE> (Control-L) can be entered with <CODE>C-q C-l</CODE>.
+<P>
+<P>
+<P>
+<HR>
+Next
+<A HREF="faq-3.html">Previous</A>
+<A HREF="faq.html#toc4">Contents</A>
+</BODY>
+</HTML>
diff --git a/Build/source/utils/xindy/doc/faq.html b/Build/source/utils/xindy/doc/faq.html
new file mode 100644
index 00000000000..d049b766693
--- /dev/null
+++ b/Build/source/utils/xindy/doc/faq.html
@@ -0,0 +1,90 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <TITLE>XINDY FAQ</TITLE>
+ <LINK HREF="faq-1.html" REL=next>
+
+
+</HEAD>
+<BODY>
+<A HREF="faq-1.html">Next</A>
+Previous
+Contents
+<HR>
+<H1>XINDY FAQ</H1>
+
+<H2>Or: <SF>xindy</SF> by Topic</H2>
+<H2>Roger Kehr</H2>
+<H3>Computer Science Department, Technical University of Darmstadt</H3>
+ and
+<H2>Joachim Schrod</H2>
+<H3>Joachim Schrod Net &amp; Publication Consultance GmbH</H3>
+$Revision: 1.2 $, $Date: 2004/05/24 21:43:16 $, for xindy version 2.2
+<P><HR>
+<EM> The <SF>xindy</SF> FAQ presents answers to questions that are not
+adequately covered in other parts of the documentation, or are hard to
+find. The FAQ has been constructed from the <EM><SF>xindy</SF> by Topic</EM>
+manual. The most up-to-date version of this FAQ can be obtained from
+the <SF>xindy</SF> homepage at
+<A HREF="http://www.xindy.org/doc/faq.html">http://www.xindy.org/doc/faq.html</A>.
+<p>
+While the content of this document is still valid, it has not been
+updated in years and doesn't describe new developments. In particular,
+it doesn't mention the many languages that are supported by Thomas
+Henlich's <EM>make-rules</EM> system, and also doesn't know anything about
+the new commands that got introduced with the "LaTeX Companion
+Release". So, caveat. We don't want to throw out the document, though,
+since it still contains lots of useful information that's not
+available elsewhere.</EM>
+<HR>
+<P>
+<H2><A NAME="toc1">1.</A> <A HREF="faq-1.html">General Questions</A></H2>
+
+<UL>
+<LI><A HREF="faq-1.html#ss1.1">1.1 Why a completely new indexing tool? <CODE>makeindex</CODE> works fine!</A>
+<LI><A HREF="faq-1.html#ss1.2">1.2 I'm an old <CODE>makeindex</CODE> wizard. What does <SF>xindy</SF> offer that <CODE>makeindex</CODE> doesn't?</A>
+</UL>
+<P>
+<H2><A NAME="toc2">2.</A> <A HREF="faq-2.html"><SF>xindy</SF> Usage</A></H2>
+
+<UL>
+<LI><A HREF="faq-2.html#ss2.1">2.1 I don't want to write style files. How can I proceed?</A>
+<LI><A HREF="faq-2.html#ss2.2">2.2 How do I use <CODE>makeindex4</CODE>?</A>
+<LI><A HREF="faq-2.html#ss2.3">2.3 How works <CODE>makeindex4</CODE>?</A>
+</UL>
+<P>
+<H2><A NAME="toc3">3.</A> <A HREF="faq-3.html"><SF>xindy</SF> and LaTeX</A></H2>
+
+<UL>
+<LI><A HREF="faq-3.html#ss3.1">3.1 What is <CODE>tex2xindy</CODE>?</A>
+<LI><A HREF="faq-3.html#ss3.2">3.2 What LaTeX-package should I use in conjunction with xindy?</A>
+</UL>
+<P>
+<H2><A NAME="toc4">4.</A> <A HREF="faq-4.html">Style Files</A></H2>
+
+<UL>
+<LI><A HREF="faq-4.html#ss4.1">4.1 Eventually, I decided to write my first index style. How can I start?</A>
+<LI><A HREF="faq-4.html#ss4.2">4.2 How to write my first index style?</A>
+<LI><A HREF="faq-4.html#ss4.3">4.3 How works the actual key feature of <CODE>makeindex</CODE> with <SF>xindy</SF>?</A>
+<LI><A HREF="faq-4.html#ss4.4">4.4 I want to process an index for my native language. What must I do?</A>
+<LI><A HREF="faq-4.html#ss4.5">4.5 In my index the capitalized words appear after the lowercase words. Why?</A>
+<LI><A HREF="faq-4.html#ss4.6">4.6 In my index there are no letter groups, yet!</A>
+<LI><A HREF="faq-4.html#ss4.7">4.7 How can I get rid of any formatting information in the keyword?</A>
+<LI><A HREF="faq-4.html#ss4.8">4.8 In my index the word <EM>-foo</EM> appears before <EM>bar</EM>. What must I do?</A>
+<LI><A HREF="faq-4.html#ss4.9">4.9 I want to use letter ordering instead of word ordering in my index.</A>
+<LI><A HREF="faq-4.html#ss4.10">4.10 My document does not have page numbers, but a different scheme. What must I do?</A>
+<LI><A HREF="faq-4.html#ss4.11">4.11 I don't want to have ranges in my index. What can I do?</A>
+<LI><A HREF="faq-4.html#ss4.12">4.12 I want to markup ranges of different length differently. How do I accomplish this?</A>
+<LI><A HREF="faq-4.html#ss4.13">4.13 I need to suppress some of the markup tags. How can I do this?</A>
+<LI><A HREF="faq-4.html#ss4.14">4.14 Whats it all about those cross references?</A>
+<LI><A HREF="faq-4.html#ss4.15">4.15 The keyword mappings don't work as expected!</A>
+<LI><A HREF="faq-4.html#ss4.16">4.16 I'm totally confused by the markup scheme!</A>
+<LI><A HREF="faq-4.html#ss4.17">4.17 What editor should I use when writing xindy style files?</A>
+</UL>
+<HR>
+<A HREF="faq-1.html">Next</A>
+Previous
+Contents
+</BODY>
+</HTML>
diff --git a/Build/source/utils/xindy/doc/index.gif b/Build/source/utils/xindy/doc/index.gif
new file mode 100644
index 00000000000..74f581c4b85
--- /dev/null
+++ b/Build/source/utils/xindy/doc/index.gif
Binary files differ
diff --git a/Build/source/utils/xindy/doc/makeindex4.pdf b/Build/source/utils/xindy/doc/makeindex4.pdf
new file mode 100644
index 00000000000..ec03477a43d
--- /dev/null
+++ b/Build/source/utils/xindy/doc/makeindex4.pdf
Binary files differ
diff --git a/Build/source/utils/xindy/doc/manual-1.html b/Build/source/utils/xindy/doc/manual-1.html
new file mode 100644
index 00000000000..40fc1db4349
--- /dev/null
+++ b/Build/source/utils/xindy/doc/manual-1.html
@@ -0,0 +1,42 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <TITLE>xindy Manual: About this Manual</TITLE>
+ <LINK HREF="manual-2.html" REL=next>
+
+ <LINK HREF="manual.html#toc1" REL=contents>
+</HEAD>
+<BODY>
+<A HREF="manual-2.html">Next</A>
+Previous
+<A HREF="manual.html#toc1">Contents</A>
+<HR>
+<H2><A NAME="s1">1. About this Manual</A></H2>
+
+<P>We assume that the reader is already familiar with the task of an
+index processor and has basic experience in using a markup-based
+document preparation systems such as TeX/LaTeX [1, 2],
+the roff-family, or SGML-based systems (e.g. its instance HTML).
+<P>This document is structured as follows. The second part gives an
+overview on the index model that is used by our system and we define
+general concepts and terms. The third part contains a list of all
+index style commands, their syntax, and a description of their
+purpose. The reader should at least have read the first part of the
+manual to understand the basic terminology to be able to use the
+command reference. The fourth
+part describes the different processing phases the system runs
+through.
+<P>Invocation of <SF>xindy</SF> is not explained here. Please refer to the
+manual pages of the commands <CODE>xindy</CODE>, <CODE>texindy</CODE>,
+<CODE>makeindex4</CODE>, and to the 2nd edition of the LaTeX Companion. The
+<SF>xindy</SF> Web Site has more documentation, too.
+<P>
+<P>
+<P>
+<HR>
+<A HREF="manual-2.html">Next</A>
+Previous
+<A HREF="manual.html#toc1">Contents</A>
+</BODY>
+</HTML>
diff --git a/Build/source/utils/xindy/doc/manual-2.html b/Build/source/utils/xindy/doc/manual-2.html
new file mode 100644
index 00000000000..c3a7a87be77
--- /dev/null
+++ b/Build/source/utils/xindy/doc/manual-2.html
@@ -0,0 +1,302 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <TITLE>xindy Manual: How the Index Processor Works</TITLE>
+ <LINK HREF="manual-3.html" REL=next>
+ <LINK HREF="manual-1.html" REL=previous>
+ <LINK HREF="manual.html#toc2" REL=contents>
+</HEAD>
+<BODY>
+<A HREF="manual-3.html">Next</A>
+<A HREF="manual-1.html">Previous</A>
+<A HREF="manual.html#toc2">Contents</A>
+<HR>
+<H2><A NAME="how-works"></A> <A NAME="s2">2. How the Index Processor Works</A></H2>
+
+<P>
+<P>
+<H2><A NAME="ss2.1">2.1 Data Flow</A>
+</H2>
+
+<P>Usually document preparation systems produce some form data that
+describe the <EM>index entries</EM> and the <EM>locations</EM> they point to.
+This data is called the <EM>raw index</EM> since it consists of raw data
+which contains structured information about the entries of the index.
+The raw index is fed into the index processor and is processed
+according to a specification called the <EM>index style</EM>. This is a
+user-definable description how the index is to be processed, what
+sort rules for the keywords should be used, which kind of locations
+may appear, and finally, what tags should be emitted when writing the
+index into the output file. The result is sometimes fed back into the
+document preparation system, as it is in the case of TeX, or used
+otherwise. The following figure illustrates this embedding into the
+document preparation process.
+<P>
+<FIGURE>
+<EPS FILE="dataflow.eps">
+<IMG SRC="dataflow.gif">
+</FIGURE>
+<P>The <SF>xindy</SF> system is oriented on book-like indexes in a form that
+is described later in detail. The format of the input data is fixed
+and a small tool that converts some system dependent raw index in a
+form suitable for <SF>xindy</SF> should not be a big hurdle. The user is
+normally not involved in the correct format suitable for <SF>xindy</SF>
+and some tools will make this work invisible to him.
+<P>In contrast, the output of the <SF>xindy</SF> system is highly
+configurable and can produce a variety of different markups.
+Additionally, the way <SF>xindy</SF> processes the index data can be
+parametrized and controlled in many ways and gives the user a powerful
+framework for describing complex indexes. The user can tell <SF>xindy</SF>
+how it should produce an output according to his wishes or simply use
+some of the predefined styles that come with the distribution.
+<P>
+<P>
+<P>
+<P>
+<H2><A NAME="general-concepts"></A> <A NAME="ss2.2">2.2 General Concepts and Terms</A>
+</H2>
+
+<P>In the following sections we introduce some terms that are necessary
+to understand the way <SF>xindy</SF> works.
+<P>The development of <SF>xindy</SF> started with the devlopment of a model
+of a <EM>book-like</EM> index. This rather vague term will now be fleshed
+out by giving a semi-formal description of the model. If the structure
+of an index conforms to this model it can be processed by <SF>xindy</SF>.
+We first present a diagram that describes the structure of a processed
+index. It is a hierarchical recursive data structure which we will
+describe now.
+<P>
+<FIGURE>
+<EPS FILE="index.eps">
+<IMG SRC="index.gif">
+</FIGURE>
+<P>Boxed objects contain elements from the raw index such as the keywords
+or the location reference layers. We start from the root of the
+diagram and explain the different elements.
+<P>
+<P>
+<P>
+<DL>
+<P>
+<DT><B>index</B><DD><P>An index consists of a list of <SF>letter-groups</SF>.
+<P>
+<P>
+<A NAME="def letter-group"></A> <DT><B>letter-group</B><DD><P>The letter groups serve as containers for
+<SF>indexentries</SF>. The letter groups are intended to group all
+index entries sharing a common <SF>keyword</SF> prefix, allowing the
+assignment of a specific markup for each group. For example, indexes
+are often organized in a way that new index entries beginning with a
+new letter are separated by a specific markup. The following example
+illustrates this style.
+<P>
+<PRE>
+ B
+ bread 25, 27
+ butter 26
+
+ M
+ marmalade 19
+ milk 21
+</PRE>
+<P>Here we have two letter groups for the letters `B' and `M' because the
+keywords `bread' and `butter' share the same prefix `b' and
+`marmalade' and `milk' share the prefix `m'. <SF>xindy</SF> can be advised
+to define arbitrary letter groups with a particular markup for each of
+them. See command <CODE>define-letter-group</CODE> for further details.
+<P>
+<P>
+<DT><B>indexentry</B><DD><P>An index entry consists of three components: the
+<SF>keyword</SF> and optionally the list of <SF>location-class-groups</SF> and
+the sub-<SF>indexentries</SF>. An example:
+<P>
+<PRE>
+ bread 25-30
+ brown 26
+ white 27
+</PRE>
+<P>This index entry consists of the keyword `bread', the
+location class list `25-30' and the sub-entries `brown 26' and `white
+27'. The sub-entries themselves are complete index entries as well,
+forming a recursive data structure.
+<P>
+<P>
+<DT><B>keyword</B><DD><P>The keyword is the identifier of an index entry. It
+consists of a list of strings being the <EM>key</EM> if the index entry. In
+our model the keyword constists of a list of strings, since indexes
+are often organized hierarchically with different layers. In the
+example
+<P>
+<PRE>
+ bread 25-30
+ bread, brown 26
+ bread, white 27
+</PRE>
+<P>we have keywords `bread', `bread, brown' and `bread, white'.
+<P>A keyword is actually separated into four different keys. The
+<SF>main-key</SF> is the key that is specified from the author who indexes
+a document. The <SF>merge-key</SF> is derived from the main key with the
+so-called <EM>merge mapping</EM>. This mapping is accomplished with a set
+of rewrite rules. The <SF>sort-key</SF> is derived from the merge key with
+another set of rewrite rules called the <EM>sort mapping</EM>. The
+<SF>print-key</SF> can be specified by the user explicitely or, if it is
+ommited, equals the main key. The rewrite rules consist of string
+substitutions that also include regular expression features.
+<P>The following figure describes this:
+<P>
+<FIGURE>
+<EPS FILE="mappings.eps">
+<IMG SRC="mappings.gif">
+</FIGURE>
+<P>
+<P>The <SF>merge-key</SF> is necessary to define the equality of
+index entry keys. See command <CODE>merge-rule</CODE> for further details about
+defining the merge mapping.
+<P>The <SF>sort-key</SF> is necessary to define a total order on the
+keywords. Since we need a scheme that is independent from any specific
+character set such as ASCII or ISO-Latin, we must be able to define
+completely new alphabets. The index entries are then sorted according
+to the ISO-Latin alphabet. See the command <CODE>sort-rule</CODE> for an
+explanation how these mapping can be specified.
+<P>The <SF>print-key</SF> is used for the final markup and contains the
+string that appears in the generated markup.
+<P>
+<P>
+<DT><B>location-class-group</B><DD><P>There exist two kinds of
+location class groups namely <SF>location-reference-groups</SF> and
+<SF>cross-reference-groups</SF>.
+<P>
+<DT><B>location-reference-group</B><DD><P>consists of a list of
+<SF>attribute-groups</SF>.
+<P>
+<P>
+<DT><B>attribute-groups</B><DD><P>Each <SF>location-reference-group</SF> consists of
+a list of <SF>attribute-groups</SF>. Attribute groups are defined by a set
+of <SF>attributes</SF>. In the markup phase, all location references are
+sorted according to the group number their attributes belong to.
+Additionally all location references of a particular attribute group
+appear together in the index.
+<P>See command <CODE>define-attribute-groups</CODE> for further information about
+the handling of attribute-groups.
+<P>An attribute group consists of a list of <SF>location-references</SF>
+and/or <SF>ranges</SF>.
+<P>
+<P>
+<A NAME="def locref-class"></A> <DT><B>location-reference-class, location-reference, location</B><DD><P>Each
+index entry of an index references at least one <SF>location</SF> in the
+document. A <SF>location</SF> is a logical or physical part of a document,
+such as a single page, a section or subsection, etc. The symbolic name
+of a location is called a <SF>location-reference</SF>. The
+location reference is always represented as a string (a sequence of
+characters). Each location reference is associated a special tag
+called <SF>attribute</SF>. The following examples may give you an idea how
+location references could look like.
+<P>
+<BLOCKQUOTE>
+<CODE>"25" </CODE> represents a page number.
+</BLOCKQUOTE>
+<P>
+<BLOCKQUOTE>
+<CODE>"Chapter-3"</CODE> represents the third chapter of a document.
+</BLOCKQUOTE>
+<P>
+<BLOCKQUOTE>
+<CODE>"A-I" </CODE> represents the first page, written in uppercase roman
+numerals of the appendix `A', separated by a hyphen.
+</BLOCKQUOTE>
+<P>
+<BLOCKQUOTE>
+<CODE>"2.3.4" </CODE> represents the sub-sub-section 2.3.4 of a document.
+</BLOCKQUOTE>
+<P>As we can see, the location references are often composed
+hierarchically of smaller entities, such as numbers or names. All
+location references that belong to the same class form a
+<SF>location-class</SF>. A location class is composed of <SF>alphabets</SF>
+and <SF>separators</SF>. See command <CODE>define-location-class</CODE> for a
+description how classes can be defined.
+<P>
+<P>
+<DT><B>alphabet, separator</B><DD><P>As we have seen in the previous section,
+location classes consist of alphabets and separators. xindy has the
+following built-in set of basic alphabets:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+&lt;tag/&lt;tt/arabic-numbers// contains all non-negative numbers beginning
+with zero: 0, 1, 2, ....
+
+&lt;tag/&lt;tt/roman-numerals-uppercase// the roman numerals I, II, III,
+(IIII/IV), V, ... It recognizes the old and new roman numeral system.
+
+&lt;tag/&lt;tt/roman-numerals-lowercase// the same for the lowercase roman
+numerals.
+
+&lt;tag/&lt;tt/ALPHA// the US-ASCII alphabet (uppercase letters).
+
+&lt;tag/&lt;tt/alpha// the US-ASCII alphabet (lowercase letters).
+
+&lt;tag/&lt;tt/digits// the digits 0, 1, 2, 3, 4, 5, 6, 7, 8 and 9 in this
+order.
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>The user is free to define new alphabets as he wishes. See the
+commands <CODE>define-alphabet</CODE> and <CODE>define-enumeration</CODE> for further
+details.
+<P>A complete location class can be defined by composing alphabets and
+separators. The location class of the example <CODE>"A-I"</CODE> can be
+defined as follows
+<P>
+<PRE>
+ (define-location-class "appendix"
+ (ALPHA "-" roman-numerals-uppercase))
+</PRE>
+<P>This is a list that completely describes all possible instances of
+this location class. Other valid members are <CODE>A-II</CODE>, <CODE>B-VI</CODE>,
+etc. Location classes are defined with the command
+<CODE>define-location-class</CODE>.
+<P><SF>xindy</SF> reads the incoming strings representing location references
+and tries to match them against a previously defined location class.
+There exist no predefined location classes.
+<P>
+<DT><B>range</B><DD><P>A <SF>range</SF> is a pair of <SF>location-references</SF>. A
+sequence of location references following one another is transformed
+into an range if the length of the sequence exceeds a certain
+user-definable limit. For example, the location references 11, 12, 13
+and&nbsp;14 may be transformed into the range 11--14. See command
+<CODE>define-location-class</CODE> for further details.
+<P>
+<P>
+<DT><B>cross-reference-group</B><DD><P>Container for all
+<SF>cross-references</SF> of a particular <SF>cross-reference-class</SF>.
+<P>
+<P>
+<A NAME="def crossref-class"></A> <DT><B>cross-reference-class, cross-reference</B><DD><P>A <SF>cross-reference</SF> is
+an unstructured reference. <SF>Cross-reference-classes</SF> are used to
+define different classes of cross references. All elements of a
+cross reference class appear together in the index. A cross reference
+consists of a list of strings.
+<P>
+<P>
+<DT><B>attributes</B><DD><P>Each location reference contains a so-called
+<SF>attribute</SF>. Attributes may be used to give a location reference a
+different meaning that may influence the processing and markup of this
+reference. Sometimes location references pointing to semantically
+different locations such as a definition or a usage of a term are
+tagged differently. They often appear in <EM>italics</EM> or <B>boldface</B>
+indicating this difference. An attribute may now be used to express
+this difference. Since <SF>xindy</SF> needs to know the possible
+attributes before the index entries are read in, the command
+<CODE>define-attributes</CODE> must be used to define a set of attributes and
+how they interact.
+<P>
+</DL>
+<P>
+<P>
+<P>
+<P>
+<HR>
+<A HREF="manual-3.html">Next</A>
+<A HREF="manual-1.html">Previous</A>
+<A HREF="manual.html#toc2">Contents</A>
+</BODY>
+</HTML>
diff --git a/Build/source/utils/xindy/doc/manual-3.html b/Build/source/utils/xindy/doc/manual-3.html
new file mode 100644
index 00000000000..3520de7f1ea
--- /dev/null
+++ b/Build/source/utils/xindy/doc/manual-3.html
@@ -0,0 +1,1160 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <TITLE>xindy Manual: Command List</TITLE>
+ <LINK HREF="manual-4.html" REL=next>
+ <LINK HREF="manual-2.html" REL=previous>
+ <LINK HREF="manual.html#toc3" REL=contents>
+</HEAD>
+<BODY>
+<A HREF="manual-4.html">Next</A>
+<A HREF="manual-2.html">Previous</A>
+<A HREF="manual.html#toc3">Contents</A>
+<HR>
+<H2><A NAME="s3">3. Command List</A></H2>
+
+<P>Here is the complete list of <SF>xindy</SF>'s commands that may be used in
+the index style. The symbol <CODE>name</CODE> always refers to a string. We
+separate the commands into the <EM>processing</EM> and
+<EM>markup</EM> commands. The commands are listed in alphabetical order.
+<P>The parenthesis `<CODE>[</CODE>' and `<CODE>]</CODE>' denote optional parts of the
+syntax and `<CODE>{</CODE>' and `<CODE>}</CODE>' denote the grouping of elements. A
+vertical bar indicates alternatives. However, the enclosing round
+braces <EM>are</EM> part of the syntax and must be supplied.
+<P>
+<P>
+<H2><A NAME="ss3.1">3.1 Processing Commands</A>
+</H2>
+
+<P>Here follows the list of processing commands.
+<P>
+<A NAME="define-alphabet"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(define-alphabet name string-list)
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Defines <CODE>name</CODE> to be the alphabet consisting of all elements of the
+<CODE>string-list</CODE>. Examples:
+<P>
+<PRE>
+ (define-alphabet "example-alphabet" ("An" "Example" "Alphabet"))
+</PRE>
+<P>defines an alphabet consisting of exactly three symbols. For the
+successor relationship holds: <CODE>succ("An")="Example"</CODE> and
+<CODE>succ("Example")="Alphabet"</CODE>. The built-in alphabet <CODE>digits</CODE> is
+defined as follows:
+<P>
+<PRE>
+ (define-alphabet "digits"
+ ("0" "1" "2" "3" "4" "5" "6" "7" "8" "9"))
+</PRE>
+<P>
+<P>
+<P>
+<A NAME="define-attributes"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(define-attributes attribute-list)
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Defines all attributes the raw index may contain. Parameter
+<CODE>attribute-list</CODE> is a list of list of strings. The nesting level
+must not be more than&nbsp;2. So <CODE>(..(..)..)</CODE> is allowed, whereas
+<CODE>(..(..(..)..)..)</CODE> is not.
+<P>The list has two kinds of elements: strings and list of strings. A
+single string is treated as if it were a single element list. So the
+lists <CODE>("definition")</CODE> and <CODE>( ("definition") )</CODE> are equivalent.
+All elements forming a list are a so-called <EM>attribute group</EM>. The
+members of a group are written to the output file before any member
+of the following groups are written.
+<P>Examples of valid attributes lists are:
+<P><CODE>("definition" "usage")</CODE> defines two attribute groups. The first
+one contains all references with the attribute <CODE>definition</CODE> and the
+second one all with the attribute <CODE>usage</CODE>.
+<P><CODE>(("definition" "important") "usage")</CODE> defines two attribute
+groups. The first one contains all references with the attributes
+<CODE>definition</CODE> or <CODE>important</CODE> and the second one all with the
+attribute <CODE>usage</CODE>. In the attribute group <CODE>("definition"
+"important")</CODE> the attribute <CODE>definition</CODE> overrides <CODE>important</CODE>.
+<P>
+<P>
+<P>
+<A NAME="define-crossref-class"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(define-crossref-class name [:unverified])
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Defines <CODE>name</CODE> to be a class of cross references. We distinguish
+two types of cross reference classes. <EM>Verified</EM> cross reference
+classes can be checked for dangling references. If for instance a
+cross reference points to the non-existent keyword `foo' a warning is
+issued and the user is advised to correct the invalid cross reference.
+This is the default. If for some reasons this mechanism must be
+deactivated the switch <CODE>:unverified</CODE> can be used to suppress this
+behaviour.
+<P>
+<P>
+<A NAME="define-letter-group"></A>
+<A NAME="define-letter-groups"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(define-letter-group name [:before lgname] [:after lgname]
+ [:prefixes list-of-prefixes])
+
+(define-letter-groups list-of-letter-groups)
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This command defines a letter group with name <CODE>name</CODE>, which must be
+a string value, grouping all index entries that have a <EM>sort key</EM>
+beginning with the prefix <CODE>name</CODE>. The command
+<P>
+<PRE>
+ (define-letter-group "a")
+</PRE>
+<P>is equivalent to the command
+<P>
+<PRE>
+ (define-letter-group "a" :prefixes ("a"))
+</PRE>
+<P>Using the latter form one can associate more than one prefix with a
+given letter group. Also further prefixes can be added to an already
+existing letter group by simply defining the same letter group again.
+This results not in a redefinition but in adding more prefixes to the
+currently defined prefixes.
+<P>Example:
+<P>
+<PRE>
+ (define-letter-group "a")
+</PRE>
+<P>defines a letter group containing all index entries beginning with the
+string <CODE>"a"</CODE>.
+<P>
+<PRE>
+ (define-letter-group "c" :after "a")
+</PRE>
+<P>defines a letter group containing all index entries beginning with the
+string <CODE>"c"</CODE>. The letter group appears behind the letter group "a"
+<P>
+<PRE>
+ (define-letter-group "b" :after "a" :before "c")
+</PRE>
+<P>inserts letter group "b" between letter group "a" and "c". This allows
+incremental definition of letter groups by extending already defined
+ones.
+<P>The arguments <CODE>:after</CODE> and <CODE>:before</CODE> define a partial order on
+the letter groups. <SF>xindy</SF> tries to convert this partial order into
+a total one. If this is impossible due to circular definitions, an
+error is reported. If more than one possible total ordering can
+result, it is left open which one is used, so one should always define
+a complete total order.
+<P>The command <CODE>define-letter-groups</CODE> (with an `s' at the end) is
+simply an abbreviation for a sequence of
+<CODE>define-letter-group</CODE> definitions where the elements are ordered in
+the ordering given by the list. Example:
+<P>
+<PRE>
+ (define-letter-groups ("a" "b" "c")
+</PRE>
+<P>equals the definitions
+<P>
+<PRE>
+ (define-letter-group "a")
+ (define-letter-group "b" :after "a")
+ (define-letter-group "c" :after "b")
+</PRE>
+<P>See also commands <CODE>markup-letter-group-list</CODE> and
+<CODE>markup-letter-group</CODE> for further information.
+<P>
+<P>
+<P>
+<A NAME="define-location-class"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(define-location-class name layer-list
+ [:min-range-length num]
+ [:hierdepth depth]
+ [:var])
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Defines <CODE>name</CODE> to be a location class consisting of the given list
+of layers. A list of layers consists of names of basetypes and/or
+strings representing separators. Separators must follow the
+keyword argument <CODE>:sep</CODE>. If the keyword <CODE>:min-range-length</CODE> is
+specified we define the <EM>minimum range length</EM> to be used when
+building ranges. The argument <CODE>num</CODE> must be a positive integer
+number or the keyword <CODE>none</CODE> in which case the building of ranges
+is disallowed. If the switch <CODE>:var</CODE> is specified the declared class
+is of type <EM>variable</EM>, i.e. it is a <EM>var-location-class</EM>. Since
+building of ranges is currently only allowed for standard classes
+<CODE>:var</CODE> and <CODE>:min-range-length</CODE> must not be used together. The
+keyword argument <CODE>:hierdepth</CODE> can be used to declare that the
+location references have to be tagged in a hierarchical form. Its
+argument <CODE>depth</CODE> must be an integer number indicating the number of
+layers the hierarchy does contain. See command
+<CODE>markup-locref-list</CODE> for more information. Examples:
+<P>
+<PRE>
+ (define-location-class "page-numbers" ("arabic-numbers")
+ :minimum-range-length 3)
+</PRE>
+<P>Defines the location class <CODE>page-numbers</CODE> consisting of one layer
+which is the alphabet <CODE>arabic-numbers</CODE>. Since the minimum
+range length is set to 3 the location references 2, 3 and 4 don't form
+a range because the range length is only 2. But the references 6, 7,
+8, and 9 are enough to form a range. Some example instances of this
+class are <CODE>0</CODE>, <CODE>1</CODE>, ... <CODE>2313</CODE>, etc.
+<P>
+<PRE>
+ (define-location-class "sections" :var
+ ("arabic-numbers" :sep "."
+ "arabic-numbers" :sep "."
+ "arabic-numbers"))
+</PRE>
+<P>defines a variable location class. Valid instances are <CODE>1</CODE>,
+<CODE>1.1</CODE>, <CODE>1.2</CODE>, <CODE>2</CODE>, <CODE>2.4.5</CODE>, but none of <CODE>2-3</CODE> (wrong
+separator), <CODE>1.2.3.4</CODE> (more than 3 layers), <CODE>2.3.iv</CODE> (roman
+number instead of arabic one).
+<P>
+<P>
+<P>
+<A NAME="define-location-class-order"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(define-location-class-order list)
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Defines the order in which the location classes are written to the
+output file. The parameter <CODE>list</CODE> is a list of names of
+location classes. Examples:
+<P>
+<PRE>
+ (define-location-class-order
+ ("page-numbers" "sections" "xrefs"))
+</PRE>
+<P>tells the system that the page numbers should appear before the
+section numbers and that the cross references should appear at the
+end. If this command is omitted, the declaration order of the
+location classes in the index style is implicitly used as the output
+order. In the case that a location class does not appear in the list,
+the output may behave unexpectedly, so one should always enumerate all
+used location classes when using this command.
+<P>
+<P>
+<P>
+<A NAME="define-rule-set"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(define-rule-set name
+ [ :inherit-from ("rule-set" "rule-set-2") ]
+ :rules (&lt;rule>...) )
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>A complete specification of a multi-phase sorting process for a
+language requires that some rules have to appear in several subsequent
+sorting phases. Rule sets can be used to define a set of rules that
+can be instantiated in an arbitrary sorting phase. Basically, they
+offer means to separate the definition of sorting rules from their
+instantiation, hence, acting as a wrapper for calls to <CODE>sort-rule</CODE>.
+They do not add new functionality that is not already present with
+<CODE>sort-rule</CODE>.
+<P>A rule can be of the form:
+<P>
+<PRE>
+ &lt;rule> ::= ("pattern" "replacement"
+ [:string|:bregexp|:egegexp] [:again])
+</PRE>
+<P>The following incomplete example defines a new rule set of name
+<CODE>isolatin1-tolower</CODE> that inherits definitions from rule set
+<CODE>latin-tolower</CODE>, overriding or adding the sort rules in the list of
+<CODE>:rules</CODE>.
+<P>
+<PRE>
+ (define-rule-set "isolatin1-tolower"
+
+ :inherit-from ("latin-tolower")
+
+ :rules (("À" "à" :string :again)
+ ("Á" "á" :string :again)
+ ("Â" "â" :string :again)
+ ("Ã" "ã" :string :again)
+ ("Ä" "ä" :string :again)
+ ("Å" "å" :string :again)
+ ("Æ" "æ" :string :again)
+ ...
+ )
+ ...)
+</PRE>
+<P>Rule sets can be instantiated with the command <CODE>use-rule-set</CODE>. For
+further descriptions on the sorting model refer to the command
+<CODE>sort-rule</CODE>.
+<P>
+<P>
+<A NAME="define-sort-rule-orientations"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(define-sort-rule-orientations (orientations...))
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Defines the order for the different sorting phases. The currently
+implemented <EM>orientations</EM> are <CODE>forward</CODE> and <CODE>backward</CODE>. This
+command must precede all <CODE>sort-rule</CODE> commands in an index style. It
+defines the orientations and implicitly sets the maximum number of
+sorting phases performed.
+<P>For further descriptions on the sorting model refer to the command
+<CODE>sort-rule</CODE>.
+<P>
+<P>
+<P>
+<A NAME="merge-rule"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(merge-rule pattern replacement [:again]
+ [:bregexp | :eregexp | :string])
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Defines a keyword mapping rule that can be used to generate the
+<EM>merge key</EM> from the <EM>main key</EM> of an index entry. This mapping
+is necessary to map all keywords that are differently written but
+belong to the same keyword to the same canonical keyword.
+<P>The parameter <CODE>pattern</CODE> can be a POSIX-compliant regular expression
+or an ordinary string. The implementation uses the GNU Rx regular
+expression library which implements the POSIX regular expressions.
+Regular expressions (REs) can be specified as <EM>basic regular
+expressions</EM> (BREs) or <EM>extended regular expressions</EM> (EREs). You
+can use the switch <CODE>:bregexp</CODE> to force the interpretation of the
+pattern as a BRE, or <CODE>:eregexp</CODE> to interpret it as an ERE. If you
+want <SF>xindy</SF> to interpret the pattern literally, use the switch
+<CODE>:string</CODE>. If none of these switches is selected, <SF>xindy</SF> uses
+an auto-detection mechanism to decide, if the pattern is a regular
+expression or not. If it recognizes the pattern as a RE, it interprets
+it as an ERE by default.
+<P>The parameter <CODE>replacement</CODE> must be
+a string possibly containing the special characters <CODE>&amp;</CODE>
+(substitutes for the complete match) and <CODE>\1</CODE>,...,<CODE>\9</CODE>
+(substituting for the <EM>n</EM>-th submatch. Examples:
+<P>
+<PRE>
+ (merge-rule "A" "a")
+</PRE>
+
+replaces each occurrence of the uppercase letter `<CODE>A</CODE>' with its
+lowercase counterpart.
+<P>
+<PRE>
+ (merge-rule "\~"([AEOUaeou])" "\1")
+</PRE>
+
+transforms the TeX umlaut-letters into their stripped counterparts,
+such that `<CODE>\"A</CODE>' is treated as an `<CODE>A</CODE>' afterwards.
+<P>The following sequences have a special meaning:
+<P>`<CODE>~n</CODE>' : End of line symbol (<EM>linefeed</EM>).
+<P>`<CODE>~b</CODE>' : The ISO-Latin character with the lowest ordinal number.
+<P>`<CODE>~e</CODE>' : The ISO-Latin character with the highest ordinal number.
+<P>`<CODE>~~</CODE>' : The tilde character.
+<P>`<CODE>~"</CODE>' : The double quote character.
+<P>Tilde characters and double quotes have to be quoted themselves with a
+tilde character. The special characters `<CODE>~b</CODE>' and
+`<CODE>~e</CODE>' allow the definition of arbitrary sorting orders by
+rules. In connection with an additional character every position in
+the alphabet can be described. E.g. `<CODE>m~e</CODE>' is
+lexicographically placed between `<CODE>m</CODE>' and `<CODE>n</CODE>'.
+<P>Due to efficiency, rules that just exchange characters or substitute
+constant character sequences are not treated as regular expressions.
+Therefore, instead of using the rule
+<P>
+<PRE>
+ (merge-rule "[A-Z]" "&amp;x")
+</PRE>
+<P>it is more efficient (though less comfortable) to use
+<P>
+<PRE>
+ (merge-rule "A" "Ax")
+ (merge-rule "B" "Bx")
+ ...
+ (merge-rule "Z" "Zx")
+</PRE>
+<P>Usually rules are applied in order of their definition. Rules with a
+special prefix precede those that begin with a class of characters, so
+that the search pattern `<CODE>alpha</CODE>' is checked before `<CODE>.*</CODE>', but
+`<CODE>auto</CODE>' and `<CODE>a.*</CODE>' are checked in order of their definition.
+<P>The first rule from a style file that matches the input is
+applied and the process restarts behind the substituted text. If no
+rule could be applied, the actual character is copied from the input
+and the process continues with the next character.
+<P>Sometimes it is necessary to apply rules anew to the result of a
+transformation. By specifying the keyword argument <CODE>:again</CODE> in the
+merge rule the rule is marked as <EM>mutable</EM>, which means that after
+using this rule the transformation process shall restart at the same
+place. E.g. the rule
+<P>
+<PRE>
+ (merge-rule "\$(.*)\$" "\1" :again)
+</PRE>
+<P>deletes <EM>all</EM> surrounding `<CODE>$</CODE>' symbols from the input.
+<P>See also command <CODE>sort-rule</CODE>.
+<P>
+<P>
+<A NAME="merge-to"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(merge-to attr-from attr-to [:drop])
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>A <EM>merge rule</EM> says that the attribute <CODE>attr-from</CODE> can be used
+to build ranges in <CODE>attr-to</CODE>. Both attributes must name valid
+attribute names. The switch <CODE>:drop</CODE> indicates, that the original
+location reference with attribute <CODE>attr-from</CODE> has to be dropped
+(removed), if a successful range was built with location references in
+attribute <CODE>attr-to</CODE>. A detailed description is given in the section
+about processing phases.
+<P>
+<P>
+<P>
+<A NAME="require"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(require filename)
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This command allows to load more index style modules. The module is
+searched in the directories defined in the search path. The file is
+read in and processing of the current file continues. The argument
+<CODE>filename</CODE> must be a string. This allows to decompose the
+index style into several modules that can be included into the topmost
+index style file. Example:
+<P>
+<PRE>
+ (require "french/alphabet.xdy")
+ (require "french/sort-rules.xdy")
+ (require "tex/locations.xdy")
+ (require "tex/markup.xdy")
+</PRE>
+<P>Submodules can load other submodules as well. If a file is required
+that was already loaded, the <CODE>require</CODE> command is simply ignored
+and processing continues without including this file twice. See also
+command <CODE>searchpath</CODE>.
+<P>
+<P>
+<P>
+<A NAME="searchpath"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(searchpath {path-string | path-list})
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This command adds the given paths to the list of paths, <SF>xindy</SF>
+searches for index style files. The argument <CODE>path-string</CODE> must be
+a colon-separated string of directory names. If this path ends with a
+colon the default search path is added to the end of the path list.
+Example:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+ (searchpath ".:/usr/local/lib/xindy:/usr/local/lib/xindy/english:")
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>adds the specified directories to the search path. Since the last path
+ends with a colon, the built-in search path is added at the end.
+Specifying
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+ (searchpath ("."
+ "/usr/local/lib/xindy"
+ "/usr/local/lib/xindy/english"
+ :default))
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>yields exactly the same result as the example above. Here
+<CODE>path-list</CODE> must be a list of strings and/or the keyword(s)
+<CODE>:default</CODE> and <CODE>:last</CODE>. The keyword <CODE>:default</CODE> signifies that
+the default pathnames are to be inserted at the specified position in
+the list. The keyword <CODE>:last</CODE> allows to insert the currently active
+paths at the indicated position. Since this allows to insert the
+built-in paths at any position and incrementally adding new paths to
+the search path, this version of the command ist more flexible than
+the first version.
+<P>
+<P>
+<A NAME="sort-rule"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(sort-rule pattern replacement [:run level] [:again])
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Defines a keyword mapping rule that can be used to generate the
+<EM>sort key</EM> of an index entry from the <EM>merge key</EM>. This key is
+used to sort the index entries lexicographically after they have been
+merged using the merge key.
+<P>The argument <CODE>:run</CODE> indicates that this rule is only in effect
+a the specified <EM>level</EM> (default is level 0). For a detailed
+discussion on the definition of sort rules for different layers refer
+to the documentation about the new sorting scheme
+(<CODE>new-sort-rules</CODE>) that comes with this distribution.
+<P>See command <CODE>merge-rule</CODE> for more information about keyword
+rules.
+<P>
+<P>
+<P>
+<A NAME="use-rule-set"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(use-rule-set [:run phase]
+ [:rule-set ( &lt;rule-set>... ))
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This command instantiates the gives rule sets to be in effect at
+sorting phase <CODE>phase</CODE>. The order of the rule sets given with
+argument <CODE>:rule-set</CODE> is significant. Rule set entries of rule set
+appearing at the beginning of the list override entries in rule sets
+at the end of the list.
+<P>The following example declares that in phase 0 the rule sets
+<CODE>din5007</CODE> and <CODE>isolatin1-tolower</CODE> should be active, whereas in
+phase 2 the other rule sets have to be applied.
+<P>
+<PRE>
+ (use-rule-set :run 0
+ :rule-set ("din5007" "isolatin1-tolower"))
+
+ (use-rule-set :run 1
+ :rule-set ("resolve-umlauts"
+ "resolve-sharp-s"
+ "isolatin1-tolower"
+ ))
+</PRE>
+<P>For a discussion on rule sets refer to command <CODE>define-rule-set</CODE>.
+<P>
+<P>
+<P>
+<H2><A NAME="ss3.2">3.2 Markup Commands</A>
+</H2>
+
+<P>
+<P>The following commands can be used to define the markup of the index.
+They don't have any influence on the indexing process. Since the
+markup scheme is characterized by the concept of <EM>environments</EM>,
+the syntax and naming scheme of all commands follows a simple
+structure.
+<P>The commands can be separated into <EM>environment</EM> and
+<EM>list-environment</EM> commands. All commands of the first group
+support the keyword arguments <CODE>:open</CODE> and <CODE>:close</CODE>, whereas the
+second group additionally supports the keyword argument <CODE>:sep</CODE>. If
+one of these keyword arguments is missing, the default markup tag is
+<EM>always</EM> the empty tag. The <CODE>:open</CODE> tag is always printed before
+the object itself and the <CODE>:close</CODE> tag is always printed after the
+object has been printed. If a list is printed the <CODE>:sep</CODE>tag is
+printed between two elements of the list but not before the first
+element, or after the last one. All commands dealing with a list have
+the suffix `<CODE>-list</CODE>' as part of their command name.
+<P>Since the number of commands and the heavy usage of <EM>default</EM> and
+<EM>specialized</EM> tags makes the markup somehow complex (but very
+powerful) we have added a mechanism to trace the markup tags
+<SF>xindy</SF> omits during its markup phase with the command
+<CODE>markup-trace</CODE>.
+<P>Here follows the list of markup commands in alphabetical order with
+some of the commands grouped together.
+<P>
+<P>
+<A NAME="markup-attribute-group"></A>
+<A NAME="markup-attribute-group-list"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(markup-attribute-group-list [:open string] [:close string]
+ [:sep string])
+
+(markup-attribute-group [:open string] [:close string]
+ [:group group-num])
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Location class groups consist of lists of attribute groups. The markup
+of this list can be defined with the command
+<CODE>markup-attribute-group-list</CODE>.
+<P>To allow different markup for different attribute groups the command
+<CODE>markup-attribute-group</CODE> can be specialized on the group number
+with the keyword argument <CODE>:group</CODE> which must be an integer number.
+E.g., given are the groups <CODE>("definition" "theorem")</CODE> and
+<CODE>("default")</CODE> with group numbers 0 and 1, then
+<P>
+<PRE>
+ (markup-attribute-group :open "&lt;group0>" :close "&lt;/group0>"
+ :group 0)
+
+ (markup-attribute-group :open "&lt;group1>" :close "&lt;/group1>"
+ :group 1)
+</PRE>
+<P>can be used to assign different markup for both groups in a SGML-based
+language.
+<P>
+<P>
+<A NAME="markup-crossref-layer"></A>
+<A NAME="markup-crossref-layer-list"></A>
+<A NAME="markup-crossref-list"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(markup-crossref-list [:open string] [:close string]
+ [:sep string]
+ [:class crossref-class])
+
+(markup-crossref-layer-list [:open string] [:close string]
+ [:sep string]
+ [:class crossref-class])
+
+(markup-crossref-layer [:open string] [:close string]
+ [:class crossref-class])
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>A crossref class group contains cross references of the same class.
+The separator between the classes is defined with the
+<CODE>(markup-locclass-list :sep)</CODE>-parameter. A list of cross references
+can be tagged with the command <CODE>markup-crossref-list</CODE> that
+specializes on the <CODE>:class</CODE> argument.
+<P>Each cross reference is determined by a list of layers indicating
+the target of the cross reference. To define a suitable markup for
+such a list the command <CODE>markup-crossref-layer-list</CODE> can be used.
+<P>Each layer of a cross reference can be assigned two tags that
+specialize on the class of the reference, like all other commands.
+<P>A suitable markup for a cross reference class <CODE>see</CODE> within LaTeX2e
+could look like that:
+<P>
+<PRE>
+ (markup-crossref-list :class "see" :open "\emph{see} "
+ :sep "; ")
+ (markup-crossref-layer-list :class "see" :sep ",")
+ (markup-crossref-layer :class "see"
+ :open "\textbf{" :close "}")
+</PRE>
+<P>An example output could look like
+<P>
+<BLOCKQUOTE>
+... <EM>see</EM> <B>house</B>; <B>garden</B>,<B>winter</B>; <B>greenhouse</B>
+</BLOCKQUOTE>
+<P>
+<P>
+<A NAME="markup-index"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(markup-index [:open string] [:close string]
+ [ :flat | :tree | :hierdepth depth ])
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Defines the markup tags that enclose the whole index via the
+<CODE>:open</CODE> and <CODE>:close</CODE> parameters. Examples:
+<P>
+<PRE>
+ (markup-index :open "Here comes the index~n"
+ :close "That's all folks!~n")
+</PRE>
+<P>defines that the <CODE>:open</CODE> string is printed before the rest of the
+index and the <CODE>:close</CODE> string appears after the index is printed.
+<P>Additionally one can specify the form of the generated index. It is
+possible to produce flat indexes by specifying the switch <CODE>:flat</CODE>,
+to generate a tree with the <CODE>:tree</CODE> switch or any kind of mixture
+between both by specifying the depth up to which trees shall be built
+with the parameter <CODE>:hierdepth</CODE>. Its argument <CODE>depth</CODE> is the
+number of layers that can be formed into a tree. Therefore <CODE>:flat</CODE>
+is an abbrevation of <CODE>:hierdepth 0</CODE> and <CODE>:tree</CODE> is an
+abbrevation of <CODE>:hierdepth max-depth</CODE>, with <CODE>max-depth</CODE> being
+the maximum number of layers a keyword has. An example: the keywords
+<P>
+<PRE>
+ ("tree" "binary" "AVL")
+ ("tree" "binary" "natural")
+</PRE>
+<P>can be transformed in the following ways:
+<P>A flat index (<CODE>:flat</CODE> or <CODE>:hierdepth 0</CODE>)
+<P>
+<PRE>
+ tree binary AVL
+ tree binary natural
+</PRE>
+<P>with <CODE>:hierdepth 1</CODE>
+<P>
+<PRE>
+ tree
+ binary AVL
+ binary natural
+</PRE>
+<P>and a tree (<CODE>:tree</CODE> or <CODE>:hierdepth</CODE> &gt; 1)
+<P>
+<PRE>
+ tree
+ binary
+ AVL
+ natural
+</PRE>
+<P>Most often one will create tree-like indexes or ones that are flat.
+<P>
+<P>
+<A NAME="markup-indexentry-list"></A>
+<A NAME="markup-indexentry"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(markup-indexentry-list [:open string] [:close string]
+ [:sep string] [:depth integer])
+
+(markup-indexentry [:open string] [:close string]
+ [:depth integer])
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Letter groups consists of a list of index entries. The command
+<CODE>markup-indexentry-list</CODE> defines the markup of these lists. The
+markup can be specialized on the depth if the index is hierarchically
+organized. The command
+<P>
+<PRE>
+ (markup-indexentry-list :open "\begin{IdxentList}"
+ :close "\end{IdxentList}"
+ :sep "~n")
+</PRE>
+<P>defines that the index entries of all layers are wrapped into the
+given markup tags. If additionally
+<P>
+<PRE>
+ (markup-indexentry-list :open "\begin{IdxentListII}"
+ :close "\end{IdxentListII}"
+ :sep "~n"
+ :depth 2)
+</PRE>
+<P>is defined, all index entry lists of all layers (except layer 2) are
+tagged according to the first specification, and the index entry list
+within depth 2 are tagged according to the second rule.
+<P>The command <CODE>markup-indexentry</CODE> defines the markup of an index entry
+at a given depth. Since index entries may also contain subentries and
+the markup for subentries may be different in different layers, the
+optional keyword argument <CODE>:depth</CODE> can be used to assign different
+markup for different layers. If depth is ommited the default markup
+for all possible depths is defined. The top-most index entries have
+depth 0.
+<P>
+<PRE>
+ (markup-indexentry :open "\begin{Indexentry}"
+ :close "\end{Indexentry}")
+</PRE>
+<P>defines that the index entries of all layers are wrapped into the
+given markup tags. If additionally
+<P>
+<PRE>
+ (markup-indexentry :open "\begin{IndexentryII}"
+ :close "\end{IndexentryII}"
+ :depth 2)
+</PRE>
+<P>is defined, all index entries of all layers (except layer 2) are tagged
+according to the first specification, and the index entries with depth
+2 are tagged according to the second rule.
+<P>
+<P>
+<A NAME="markup-keyword-list"></A>
+<A NAME="markup-keyword"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(markup-keyword-list [:open string] [:close string]
+ [:sep string] [:depth integer])
+
+(markup-keyword [:open string] [:close string]
+ [:depth integer])
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>
+<P>The print key of an index entry consists of a list of strings. The
+markup of this list can be defined with the command
+<CODE>markup-keyword-list</CODE>. The keyword argument <CODE>:depth</CODE> may be
+specified to define the markup of the list at a particular depth.
+<P>The keyword of an index entry consists of a list of strings. Each of
+these components is tagged with the strings defined with the command
+<CODE>markup-keyword</CODE>. Since we maybe need different markup for
+different layers, the optional keyword argument can be used to
+specialize this markup for some depth.
+<P>
+<P>
+<A NAME="markup-letter-group-list"></A>
+<A NAME="markup-letter-group"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(markup-letter-group-list [:open string] [:close string]
+ [:sep string])
+
+(markup-letter-group [:open string] [:close string] [:group group-name]
+ [:open-head string] [:close-head string]
+ [:upcase | :downcase | :capitalize])
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>The first command defines the markup of the letter group with name
+<CODE>group-name</CODE>. Since the markup of letter groups often contains the
+name of the letter group as a part of it, the other keyword arguments
+allow an additional markup for this group name. If one of the
+parameters <CODE>:open-head</CODE> and <CODE>:close-head</CODE> is specified
+additional markup is added as can be described as follows:
+<P>
+<PRE>
+ &lt;OPEN>
+ IF (:open-head OR :close-head)
+ &lt;OPEN-HEAD>
+ transformer-of(&lt;GROUP-NAME>)
+ &lt;CLOSE-HEAD>
+ FI
+ &lt;INDEXENTRIES...>
+ &lt;CLOSE>
+</PRE>
+<P>Here, <CODE>transformer-of</CODE> is a function that possibly transforms the
+string representing the group name into another string. The
+transformers we currently support can be specified with the switches
+<CODE>:upcase</CODE>, <CODE>:downcase</CODE> and <CODE>:capitalize</CODE> which result in the
+corresponding string conversions. If none of them is specified no
+transformation is done at all.
+<P>The command <CODE>markup-letter-group</CODE> defines the markup of the list of
+letter groups.
+<P>
+<P>
+<A NAME="markup-locclass-list"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(markup-locclass-list [:open string] [:close string]
+ [:sep string])
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Each index entry contains a list of location class groups. This markup
+command can be used to define the markup of this list.
+<P>
+<P>
+<A NAME="markup-locref"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(markup-locref [:open string] [:close string]
+ [:class locref-class]
+ [:attr attribute]
+ [:depth integer])
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>The markup tags of a location reference can be specialized on the
+three arguments <CODE>:class</CODE>, <CODE>:attr</CODE> and additionally, if
+sub-references are used, <CODE>:depth</CODE>. Most often one will only use a
+tag depending on the attribute. For example, all location references
+with the attribute <CODE>definition</CODE> should appear in a font series like
+bold, emphasizing the importance of this location reference; those
+with the attribute <CODE>default</CODE> in font shape italic. The markup in
+this case would not specialize on the depth or any particular class. A
+valid definition, suitable for a usage within HTML, could look like
+this.
+<P>
+<PRE>
+ (markup-locref :open "&lt;B>" :close "&lt;/B>" :attr "definition")
+ (markup-locref :open "&lt;I>" :close "&lt;/I>" :attr "default")
+</PRE>
+<P>
+<P>
+<A NAME="markup-locref-class"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(markup-locref-class [:open string] [:close string]
+ [:class locref-class])
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>All location references of a particular location reference class can
+be wrapped into the tags defined by this command. It specializes on
+the keyword argument <CODE>:class</CODE>.
+<P>
+<P>
+<A NAME="markup-locref-layer-list"></A>
+<A NAME="markup-locref-layer"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(markup-locref-layer [:open string] [:close string]
+ [:depth integer] [:layer integer]
+ [:class locref-class])
+
+(markup-locref-layer-list [:open string] [:close string]
+ [:sep string]
+ [:depth integer]
+ [:class locref-class])
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>A location reference contains a list of location reference layers. The
+second markup command can be used to markup this list. It specializes
+on the class of the location references and the depth (if
+sub-references are used).
+<P>The first command allows to tag the elements of a layer list
+differently. The first element of this list can is specialisable with
+<CODE>:layer 0</CODE>, the next element with <CODE>:layer 1</CODE>, etc. See the next
+example for an example.
+<P>
+<P>
+<A NAME="markup-locref-list"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(markup-locref-list [:open string] [:close string] [:sep string]
+ [:depth integer] [:class locref-class])
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>An attribute group contains a list of location references and/or
+ranges. Additionally a layered location reference itself may contain
+sub-references that are stored as a list of location references. We
+specialize the markup for these lists on the location class they
+belong to with the keyword argument <CODE>:class</CODE>, and on <CODE>:depth</CODE>
+that specializes on the different subentry levels when using
+location references with sub-references.
+<P>Given is a list of location references that have the class description
+<P>
+<PRE>
+ (define-location-class "Appendix"
+ ("ALPHA" :sep "-" "arabic-numbers")
+ :hierdepth 2)
+</PRE>
+<P>This location class has instances like <CODE>A-1</CODE>, <CODE>B-5</CODE>, etc. The
+keyword argument <CODE>:hierdepth 2</CODE> informs <SF>xindy</SF> to markup these
+location references in a hierarchical form. With the commands
+<P>
+<PRE>
+ (markup-locref-list :sep "; "
+ :depth 0 :class "Appendix")
+ (markup-locref-list :open " " :sep ","
+ :depth 1 :class "Appendix")
+ (markup-locref-layer :open "{\bf " :close "}" :layer 0
+ :depth 0 :class "Appendix")
+</PRE>
+<P>we obtain a markup sequence for some example data that could look like
+<P>
+<PRE>
+ {\bf A} 1,2,5; {\bf B} 5,6,9; {\bf D} 1,5,8; ...
+</PRE>
+<P>
+<P>
+<P>
+<A NAME="markup-range"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(markup-range [:open string] [:close string] [:sep string]
+ [:class locref-class]
+ [:length num] [:ignore-end])
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>A range consists of two location references. Markup can be specified
+with the <CODE>:open</CODE> and <CODE>:close</CODE> arguments and one separator given
+by the argument <CODE>:sep</CODE>.
+<P>Since both location references are tagged with markup defined by the
+command <CODE>markup-locref</CODE> a specialization on attributes or depth is
+not necessary. Specialization is allowed on the class they belong to,
+because the separator between two location refences may be different
+for each location class. Argument <CODE>:length</CODE> can be used to define
+different markup for different lengths. In conjunction with
+<CODE>:length</CODE> is may be useful not to print the second location
+reference at all. For example, one wishes to markup ranges of length 1
+in the form <EM>Xf.</EM> instead of <EM>X--Y</EM>. This can be accomplished
+with the switch <CODE>:ignore-end</CODE>.
+<P>The markup tags for a range <EM>(X,Y)</EM> can be described as follows:
+<P>
+<PRE>
+ &lt;OPEN>
+ Markup of location reference X
+ &lt;SEP>
+ IF (not :ignore-end)
+ Markup of location reference Y
+ FI
+ &lt;CLOSE>
+</PRE>
+<P>
+<P>The following tags can be used to define a range of page numbers
+(given in a location class <CODE>page-numbers</CODE>) without considering the
+open and close parameters:
+<P>
+<PRE>
+ (markup-range :sep "-" :class "page-numbers")
+</PRE>
+<P>Location ranges then appear separated by a hyphen in a form like this:
+<P>
+<PRE>
+ ..., 5-8, 19-23, ...
+</PRE>
+<P>
+<P>
+<A NAME="markup-trace"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(markup-trace [:on] [:open string] [:close string])
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This command can be used to activate the tracing of all
+markup commands <SF>xindy</SF> executes. The switch <CODE>:on</CODE> activates the
+trace. If <CODE>:on</CODE> is omitted, the command line flag <CODE>-t</CODE> can be
+used as well. All tags which are emitted but not yet defined
+explicitly by the user are tagged with a symbolic notation indicating
+the commands that must be used to define this tag. The defaults for
+the keyword argument <CODE>:open</CODE> is `<CODE>&lt;</CODE>' and for <CODE>:close</CODE> is
+`<CODE>></CODE>'. The beginning of an example output could look like:
+<P>
+<PRE>
+ &lt;INDEX:OPEN>
+ &lt;LETTER-GROUP-LIST:OPEN>
+ &lt;LETTER-GROUP:OPEN ["a"]>
+ &lt;INDEXENTRY-LIST:OPEN [0]>
+ &lt;INDEXENTRY:OPEN [0]>
+ &lt;KEYWORD-LIST:OPEN [0]>
+ &lt;KEYWORD:OPEN [0]>
+ ...
+</PRE>
+<P>We use a simple indentation scheme to make the structure of the tags
+visible. The symbolic tag <CODE>&lt;LETTER-GROUP:OPEN ["a"]></CODE> for example
+indicates that the tag that can be specified with the command
+<P>
+<PRE>
+ (markup-letter-group :open "XXX" :group "a" ... )
+</PRE>
+<P>is emitted at this point in the markup process. By incrementally
+adding markup commands to the index, more and more tags can be defined
+until the whole markup is defined. This general mechanism should allow
+everyone understand the markup process. The best is to start with a
+small index, define the complete markup and afterwards process the
+whole index. Additionally one can enclose the symbolic tags into an
+environment that is neutral to the document preparation system, such
+as a comment. For TeX this could be
+<P>
+<PRE>
+ (markup-trace :open "%%" :close "~n")
+</PRE>
+<P>or a definition in the TeX document like
+<P>
+<PRE>
+ \def\ignore#1{}
+</PRE>
+<P>combined with the command
+<P>
+<PRE>
+ (markup-trace :open "\ignore{" :close "}")
+</PRE>
+<P>
+<P>
+<P>
+<A NAME="raw-index"></A> <H2><A NAME="ss3.3">3.3 Raw Index Interface</A>
+</H2>
+
+<P>
+<P>This section can be skipped if the reader is not interested in
+adapting <SF>xindy</SF> to a new document preparation system.
+<P>The raw index is the file that represents the index that is to be
+processed. Since many different document preparation systems may use
+different forms of index representations, their output must be
+transformed in a form readable by <SF>xindy</SF>. We also could have
+written an configurable parser performing this task, but usually a
+tool written with some text processing tools such as <CODE>perl</CODE>,
+<CODE>sed</CODE> or <CODE>awk</CODE> can achieve the same task as well. Therefore,
+adapting <SF>xindy</SF> to a completely different system can mostly be
+done by writing an appropriate raw index filter.
+<P>The format of the raw index interface of <SF>xindy</SF> is defined as
+follows:
+<P>
+<A NAME="indexentry"></A>
+<BLOCKQUOTE><CODE>
+<PRE>
+(indexentry { :key string-list [:print string-list]
+ | :tkey list-of-layers }
+ [:attr string]
+ { :locref string [:open-range | :close-range]
+ | :xref string-list } )
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>The pseudo variable <EM>string</EM> is a sequence of characters
+surrounded by double quotes, e.g.
+<P>
+<PRE>
+ "Hi, it's me" "one" "a string with two \"double quotes\""
+</PRE>
+<P>are three examples of valid strings. If you need to include a
+double quote as a literal character, you must quote it itself with a
+backslash as shown in the third example. A <EM>string list</EM> is simply
+a list of strings separated by whitespaces and surrounded by round
+braces. An example of a string list is
+<P>
+<PRE>
+ ("This" "is" "a" "list" "of" "strings")
+</PRE>
+<P>So far about the syntax. The semantics of the different elements are
+described here.
+<P>
+<P>
+<DL>
+<P>
+<DT><B><CODE>:key</CODE></B><DD><P>The argument <EM>string list</EM> defines the keyword of
+the index entry. It must be a list of strings, since the keyword may
+consist of different layers such as <CODE>("heap" "fibonacci")</CODE>.
+<P>
+<DT><B><CODE>:print</CODE></B><DD><P>The optional <EM>print key</EM> defines the way the
+keyword has to be printed in the markup phase.
+<P>
+<DT><B><CODE>:tkey</CODE></B><DD><P>Another possibility to define the keys of an
+index entry is with the <CODE>:tkey</CODE> keyword argument. It can be used
+instead of the <CODE>:key</CODE> and <CODE>:print</CODE> arguments. Instead of
+specifying separately the key and the corresponding print key, we
+define the keyword by its layers. Each layer consist of a list of one
+or two strings. The first string will be interpreted as the main key,
+whereas the second one will become the print key. If the print key is
+ommited, the main key is taken instead. So the definition
+<P>
+<PRE>
+ :tkey (("This") ("is") ("a") ("bang" "BANG !!!"))
+</PRE>
+<P>is equivalent to
+<P>
+<PRE>
+ :key ("This" "is" "a" "bang")
+ :print ("This" "is" "a" "BANG !!!")
+</PRE>
+<P>
+<P>
+<DT><B><CODE>:locref</CODE></B><DD><P>The reference an index entry describes can be a
+<EM>location reference</EM> or a <EM>cross reference</EM>. The switch
+<CODE>:locref</CODE> describes a location reference. Its optional arguments
+are <CODE>:open-range</CODE> and <CODE>:close-range</CODE>. The <EM>string</EM> that must
+be supplied must somehow encode the location reference. It might look
+like the string <CODE>"25"</CODE> representing the page number 25, or
+<CODE>"Appendix-I"</CODE> representing the first appendix numbered in
+uppercase roman numerals.
+<P>
+<DT><B><CODE>:open-range</CODE>,<CODE>:close-range</CODE></B><DD><P>These are switches that do not
+take any arguments. They describe the beginning and ending of a
+<EM>range</EM>, starting or ending from the location reference that is
+given by the argument <CODE>:locref</CODE>. If they are supplied, the
+location reference may have influence on the way ranges are build.
+<P>
+<DT><B><CODE>:xref</CODE></B><DD><P>These arguments choose the second alternative. The
+argument <EM>string list</EM> of parameter <CODE>:xref</CODE> describes where the
+index entry should point to.
+<P>
+<DT><B><CODE>:attr</CODE></B><DD><P>This parameter may be used to tag a location reference
+with a certain attribute or it names the class of a cross reference.
+It may also used to associate different markup for different
+attributes in the markup phase. If this parameter is omitted or is the
+empty string, the indexentry is declared to have the attribute
+<CODE>default</CODE>.
+<P>
+</DL>
+<P>Some examples:
+<P>
+<PRE>
+ (indexentry :key ("airplane") :locref "25" :attr "default")
+</PRE>
+<P>defines an index entry with the key `airplane' indexed on page '25'.
+This index entry has the attribute <CODE>default</CODE>.
+<P>
+<PRE>
+ (indexentry :key ("house") :xref ("building") :attr "see")
+</PRE>
+<P>defines a cross reference with the key 'house' pointing to the term
+'building'. This cross reference belongs to the cross reference class
+<CODE>see</CODE>.
+<P>
+<PRE>
+ (indexentry :key ("house") :xref ("building") :open-range)
+</PRE>
+<P>is an invalid specification, since <CODE>:open-range</CODE> mustn't be used
+together with cross references.
+<P>
+<P>
+<P>
+<HR>
+<A HREF="manual-4.html">Next</A>
+<A HREF="manual-2.html">Previous</A>
+<A HREF="manual.html#toc3">Contents</A>
+</BODY>
+</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 @@
+<!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>
diff --git a/Build/source/utils/xindy/doc/manual-5.html b/Build/source/utils/xindy/doc/manual-5.html
new file mode 100644
index 00000000000..072920545aa
--- /dev/null
+++ b/Build/source/utils/xindy/doc/manual-5.html
@@ -0,0 +1,63 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <TITLE>xindy Manual: Index</TITLE>
+ <LINK HREF="manual-6.html" REL=next>
+ <LINK HREF="manual-4.html" REL=previous>
+ <LINK HREF="manual.html#toc5" REL=contents>
+</HEAD>
+<BODY>
+<A HREF="manual-6.html">Next</A>
+<A HREF="manual-4.html">Previous</A>
+<A HREF="manual.html#toc5">Contents</A>
+<HR>
+<H2><A NAME="INDEX"></A> <A NAME="s5">5. Index</A></H2>
+
+<P>
+<P><B>List of Commands</B>
+<P>
+<A HREF="manual-3.html#define-attributes">define-attributes</A><BR>
+<A HREF="manual-3.html#define-alphabet">define-alphabet</A><BR>
+<A HREF="manual-3.html#define-crossref-class">define-crossref-class</A><BR>
+<A HREF="manual-3.html#define-letter-group">define-letter-group</A><BR>
+<A HREF="manual-3.html#define-letter-groups">define-letter-groups</A><BR>
+<A HREF="manual-3.html#define-location-class">define-location-class</A><BR>
+<A HREF="manual-3.html#define-location-class-order">define-location-class-order</A><BR>
+<A HREF="manual-3.html#define-rule-set">define-rule-set</A><BR>
+<A HREF="manual-3.html#define-sort-rule-orientations">define-sort-rule-orientations</A><BR>
+<A HREF="manual-3.html#indexentry">indexentry</A><BR>
+<A HREF="manual-3.html#markup-attribute-group">markup-attribute-group</A><BR>
+<A HREF="manual-3.html#markup-attribute-group-list">markup-attribute-group-list</A><BR>
+<A HREF="manual-3.html#markup-crossref-layer">markup-crossref-layer</A><BR>
+<A HREF="manual-3.html#markup-crossref-layer-list">markup-crossref-layer-list</A><BR>
+<A HREF="manual-3.html#markup-crossref-layer">markup-crossref-layer</A><BR>
+<A HREF="manual-3.html#markup-index">markup-index</A><BR>
+<A HREF="manual-3.html#markup-indexentry">markup-indexentry</A><BR>
+<A HREF="manual-3.html#markup-indexentry-list">markup-indexentry-list</A><BR>
+<A HREF="manual-3.html#markup-keyword">markup-keyword</A><BR>
+<A HREF="manual-3.html#markup-keyword-list">markup-keyword-list</A><BR>
+<A HREF="manual-3.html#markup-letter-group">markup-letter-group</A><BR>
+<A HREF="manual-3.html#markup-letter-group-list">markup-letter-group-list</A><BR>
+<A HREF="manual-3.html#markup-locclass-list">markup-locclass-list</A><BR>
+<A HREF="manual-3.html#markup-locref">markup-locref</A><BR>
+<A HREF="manual-3.html#markup-locref-class">markup-locref-class</A><BR>
+<A HREF="manual-3.html#markup-locref-layer">markup-locref-layer</A><BR>
+<A HREF="manual-3.html#markup-locref-layer-list">markup-locref-layer-list</A><BR>
+<A HREF="manual-3.html#markup-locref-list">markup-locref-list</A><BR>
+<A HREF="manual-3.html#markup-range">markup-range</A><BR>
+<A HREF="manual-3.html#markup-trace">markup-trace</A><BR>
+<A HREF="manual-3.html#merge-rule">merge-rule</A><BR>
+<A HREF="manual-3.html#merge-to">merge-to</A><BR>
+<A HREF="manual-3.html#require">require</A><BR>
+<A HREF="manual-3.html#searchpath">searchpath</A><BR>
+<A HREF="manual-3.html#sort-rule">sort-rule</A><BR>
+<A HREF="manual-3.html#use-rule-set">use-rule-set</A><P>
+<P>
+<P>
+<HR>
+<A HREF="manual-6.html">Next</A>
+<A HREF="manual-4.html">Previous</A>
+<A HREF="manual.html#toc5">Contents</A>
+</BODY>
+</HTML>
diff --git a/Build/source/utils/xindy/doc/manual-6.html b/Build/source/utils/xindy/doc/manual-6.html
new file mode 100644
index 00000000000..dfbf33ccc91
--- /dev/null
+++ b/Build/source/utils/xindy/doc/manual-6.html
@@ -0,0 +1,53 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <TITLE>xindy Manual: References</TITLE>
+ <LINK HREF="manual-5.html" REL=previous>
+ <LINK HREF="manual.html#toc6" REL=contents>
+</HEAD>
+<BODY>
+Next
+<A HREF="manual-5.html">Previous</A>
+<A HREF="manual.html#toc6">Contents</A>
+<HR>
+<H2><A NAME="s6">6. References</A></H2>
+
+<P>
+<P>The following books and papers were referenced in this document.
+<P>
+<OL>
+<LI> D. E. Knuth, <EM>The TeXbook</EM>, Addison-Wesley, 1984
+</LI>
+<LI> Leslie Lamport, LaTeX <EM>A Document Preparation System</EM>,
+Addison-Wesley, 1986
+</LI>
+<LI> Joachim Schrod, <EM>An International Version of MakeIndex</EM>,
+Cahiers GUTenberg, 10, p81-90, 1991
+</LI>
+<LI> Pehong Chen and Michael A. Harrison, <EM>Automating Index
+Preparation</EM>, TR-87/347, University of California Berkeley, 1987
+<A NAME="makeindex"></A>
+</LI>
+<LI> Roger Kehr, <SF>xindy</SF>, <EM>Ein Flexibles Indexierungssystem</EM>,
+Studienarbeit FB Informatik, TH-Darmstadt, November 1995.
+</LI>
+<LI> Joachim Schrod and Gabor Herr, <EM>MakeIndex Version 3.0</EM>,
+Technical University Darmstadt, 1991
+</LI>
+<LI> Roger Kehr, <SF>xindy</SF> -- <EM>A Flexible Indexing System</EM>,
+Technical Report No. 11/1997, Computer Science Department, Darmstadt
+University of Technology, 1997. Also accessible from the <SF>xindy</SF>
+homepage.
+</LI>
+<LI> Roger Kehr, <SF>xindy</SF> -- <EM>A Flexible Indexing System</EM>,
+Proceedings of the EuroTeX'98, St. Malo, France, March 1998
+</LI>
+</OL>
+<P>
+<HR>
+Next
+<A HREF="manual-5.html">Previous</A>
+<A HREF="manual.html#toc6">Contents</A>
+</BODY>
+</HTML>
diff --git a/Build/source/utils/xindy/doc/manual-7.html b/Build/source/utils/xindy/doc/manual-7.html
new file mode 100644
index 00000000000..c1c26ed507a
--- /dev/null
+++ b/Build/source/utils/xindy/doc/manual-7.html
@@ -0,0 +1,53 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <TITLE>xindy Manual: References</TITLE>
+ <LINK HREF="manual-6.html" REL=previous>
+ <LINK HREF="manual.html#toc7" REL=contents>
+</HEAD>
+<BODY>
+Next
+<A HREF="manual-6.html">Previous</A>
+<A HREF="manual.html#toc7">Contents</A>
+<HR>
+<H2><A NAME="s7">7. References</A></H2>
+
+<P>
+<P>The following books and papers were referenced in this document.
+<P>
+<OL>
+<LI> D. E. Knuth, <EM>The TeXbook</EM>, Addison-Wesley, 1984
+</LI>
+<LI> Leslie Lamport, LaTeX <EM>A Document Preparation System</EM>,
+Addison-Wesley, 1986
+</LI>
+<LI> Joachim Schrod, <EM>An International Version of MakeIndex</EM>,
+Cahiers GUTenberg, 10, p81-90, 1991
+</LI>
+<LI> Pehong Chen and Michael A. Harrison, <EM>Automating Index
+Preparation</EM>, TR-87/347, University of California Berkeley, 1987
+<A NAME="makeindex"></A>
+</LI>
+<LI> Roger Kehr, <SF>xindy</SF>, <EM>Ein Flexibles Indexierungssystem</EM>,
+Studienarbeit FB Informatik, TH-Darmstadt, November 1995.
+</LI>
+<LI> Joachim Schrod and Gabor Herr, <EM>MakeIndex Version 3.0</EM>,
+Technical University Darmstadt, 1991
+</LI>
+<LI> Roger Kehr, <SF>xindy</SF> -- <EM>A Flexible Indexing System</EM>,
+Technical Report No. 11/1997, Computer Science Department, Darmstadt
+University of Technology, 1997. Also accessible from the <SF>xindy</SF>
+homepage.
+</LI>
+<LI> Roger Kehr, <SF>xindy</SF> -- <EM>A Flexible Indexing System</EM>,
+Proceedings of the EuroTeX'98, St. Malo, France, March 1998
+</LI>
+</OL>
+<P>
+<HR>
+Next
+<A HREF="manual-6.html">Previous</A>
+<A HREF="manual.html#toc7">Contents</A>
+</BODY>
+</HTML>
diff --git a/Build/source/utils/xindy/doc/manual.html b/Build/source/utils/xindy/doc/manual.html
new file mode 100644
index 00000000000..344b0e19cab
--- /dev/null
+++ b/Build/source/utils/xindy/doc/manual.html
@@ -0,0 +1,73 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <TITLE>xindy Manual</TITLE>
+ <LINK HREF="manual-1.html" REL=next>
+
+
+</HEAD>
+<BODY>
+<A HREF="manual-1.html">Next</A>
+Previous
+Contents
+<HR>
+<H1><SF>xindy</SF> Manual</H1>
+
+<H2>Roger Kehr</H2>
+<H3>Computer Science Department, Technical University of Darmstadt</H3>
+ and
+<H2>Joachim Schrod</H2>
+<H3>Joachim Schrod Net &amp; Publication Consultance GmbH</H3>
+$Revision: 1.19 $, $Date: 2004/05/24 21:43:16 $,
+for xindy version 2.2
+<P><HR>
+<EM>This is the manual of the indexing system <SF>xindy</SF>. <SF>xindy</SF>
+is a powerful and flexible framework for generating indexes for many
+kinds of documents. This document describes the <SF>xindy</SF> processing
+model, terminology, and language, but not invocation and standard modules.
+The most up-to-date version can be obtained from the <SF>xindy</SF> Web Site at
+<A HREF="http://www.xindy.org/">http://www.xindy.org/</A>.</EM>
+<HR>
+<P>
+<A HREF="manual-5.html#INDEX">Index of all xindy commands</A><P>
+<P>
+<P>
+<P>
+<H2><A NAME="toc1">1.</A> <A HREF="manual-1.html">About this Manual</A></H2>
+
+<P>
+<H2><A NAME="toc2">2.</A> <A HREF="manual-2.html">How the Index Processor Works</A></H2>
+
+<UL>
+<LI><A HREF="manual-2.html#ss2.1">2.1 Data Flow</A>
+<LI><A HREF="manual-2.html#ss2.2">2.2 General Concepts and Terms</A>
+</UL>
+<P>
+<H2><A NAME="toc3">3.</A> <A HREF="manual-3.html">Command List</A></H2>
+
+<UL>
+<LI><A HREF="manual-3.html#ss3.1">3.1 Processing Commands</A>
+<LI><A HREF="manual-3.html#ss3.2">3.2 Markup Commands</A>
+<LI><A HREF="manual-3.html#ss3.3">3.3 Raw Index Interface</A>
+</UL>
+<P>
+<H2><A NAME="toc4">4.</A> <A HREF="manual-4.html">Processing Phases</A></H2>
+
+<UL>
+<LI><A HREF="manual-4.html#ss4.1">4.1 The Startup Phase</A>
+<LI><A HREF="manual-4.html#ss4.2">4.2 The Processing Phase</A>
+<LI><A HREF="manual-4.html#ss4.3">4.3 The Markup Phase</A>
+</UL>
+<P>
+<H2><A NAME="toc5">5.</A> <A HREF="manual-5.html">Index</A></H2>
+
+<P>
+<H2><A NAME="toc6">6.</A> <A HREF="manual-6.html">References</A></H2>
+
+<HR>
+<A HREF="manual-1.html">Next</A>
+Previous
+Contents
+</BODY>
+</HTML>
diff --git a/Build/source/utils/xindy/doc/mappings.gif b/Build/source/utils/xindy/doc/mappings.gif
new file mode 100644
index 00000000000..be58722f4d9
--- /dev/null
+++ b/Build/source/utils/xindy/doc/mappings.gif
Binary files differ
diff --git a/Build/source/utils/xindy/doc/next.gif b/Build/source/utils/xindy/doc/next.gif
new file mode 100644
index 00000000000..7a2dbe955e0
--- /dev/null
+++ b/Build/source/utils/xindy/doc/next.gif
Binary files differ
diff --git a/Build/source/utils/xindy/doc/prev.gif b/Build/source/utils/xindy/doc/prev.gif
new file mode 100644
index 00000000000..aef90f1fc49
--- /dev/null
+++ b/Build/source/utils/xindy/doc/prev.gif
Binary files differ
diff --git a/Build/source/utils/xindy/doc/style-tutorial-1.html b/Build/source/utils/xindy/doc/style-tutorial-1.html
new file mode 100644
index 00000000000..890b1ecd8b9
--- /dev/null
+++ b/Build/source/utils/xindy/doc/style-tutorial-1.html
@@ -0,0 +1,92 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <TITLE>XINDY Style File Tutorial: About xindy</TITLE>
+ <LINK HREF="style-tutorial-2.html" REL=next>
+
+ <LINK HREF="style-tutorial.html#toc1" REL=contents>
+</HEAD>
+<BODY>
+<A HREF="style-tutorial-2.html">Next</A>
+Previous
+<A HREF="style-tutorial.html#toc1">Contents</A>
+<HR>
+<H2><A NAME="s1">1. About <SF>xindy</SF></A></H2>
+
+<P><SF>xindy</SF> means fle<B>x</B>ible <B>ind</B>exing s<B>y</B>stem. It is an
+indexing system that can be used to generate book-like indexes for
+arbitrary document preparation systems. This term includes systems
+such as TeX [1] and LaTeX [2], the Nroff-family
+or SGML-based systems (e.g. HTML) that process some kind of text and
+generate indexing information. It is not fixed to any specific system,
+but can be configured for a wide variety of purposes.
+<P>Authors sometimes wish to include an index into their document, but
+very often their document preparation systems aren't able to produce
+indexes on their own, or the capabilities of the built-in indexers are
+insufficient and produce ugly looking results. More often they use
+separate specialized tools for this purpose, sometimes called
+<EM>index processors</EM>.
+<P>In comparison to other index processors <SF>xindy</SF> has several
+powerful features that make it an ideal framework for describing and
+generating complex indexes. Its most interesting features are
+<P>
+<DL>
+<P>
+<DT><B>Internationality</B><DD><P><SF>xindy</SF> can be configured to process indexes
+for many languages with different letter sets and different sorting
+rules. For example, many roman languages such as Italian, French,
+Portuguese or Spanish contain accentuated letters such as &Agrave;,
+&Aacute;, &ntilde;. Other languages from northern Europe have letters
+like &Auml;, &Oslash;, &aelig; or &szlig; which often can't even be
+processed by many index processors let alone sorting them correctly
+into an index. The <SF>xindy</SF> system can be configured to process
+these alphabets by defining <EM>sort</EM> and <EM>merge rules</EM> that allow
+expressing language specific rules. One example of such a rule would
+be
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(sort-rule "ä" "ae")
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>defining that a word containing the umlaut-a will be sorted as if it
+contained the letters <CODE>ae</CODE> instead. This is one form of how the
+umlaut-a ("ä") is sorted into german indexes. With an appropriate set
+of rules on can express the complete rules of a specific language.
+<P>
+<DT><B>User Definable Location Types</B><DD><P>Locations are the entities an
+index entry points to. Often used locations are <EM>page numbers</EM>,
+<EM>section numbers</EM>, etc. <SF>xindy</SF> allows to define new kinds of
+types to be composed of basic entities like arabic numbers, roman
+numerals, letters, etc. which can be used to describe new index types.
+Examples of these entities can be books that have a page numbering
+scheme that starts from 1 for each new chapter resulting in page
+numbers of the form <EM>1-13, 2-15, 2-20</EM>, etc. This type of locations
+can often be found in computer manuals. A more complex structure is
+represented by the locations <EM>Psalm 46, 1-8</EM> and <EM>Genesis 1,
+31</EM>. Even the structure of bible verses can be described allowing
+<SF>xindy</SF> to correctly sort and process indexes for documents with a
+completely different structure.
+<P>
+<DT><B>Highly Configurable Markup</B><DD><P>Since a index processor is only one
+component in a document preparation system it ought to fit smoothly
+into the complete environment. Many text processing systems use the
+concept of <EM>environments</EM> that can be used to describe the markup
+of the text entities. Our approach is based on this concept which has
+proved to be expressive enough for most applications. As an example
+one can view systems such as TeX, SGML and its instance HTML, GNU
+Info, RTF and the Nroff-familiy of document formatters. The markup of
+an index can be defined for all of these systems in a very comfortable
+though extremly powerful way.
+<P>
+</DL>
+<P>
+<P>
+<P>
+<HR>
+<A HREF="style-tutorial-2.html">Next</A>
+Previous
+<A HREF="style-tutorial.html#toc1">Contents</A>
+</BODY>
+</HTML>
diff --git a/Build/source/utils/xindy/doc/style-tutorial-2.html b/Build/source/utils/xindy/doc/style-tutorial-2.html
new file mode 100644
index 00000000000..b5313e59d72
--- /dev/null
+++ b/Build/source/utils/xindy/doc/style-tutorial-2.html
@@ -0,0 +1,361 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <TITLE>XINDY Style File Tutorial: A Basic Introduction</TITLE>
+ <LINK HREF="style-tutorial-3.html" REL=next>
+ <LINK HREF="style-tutorial-1.html" REL=previous>
+ <LINK HREF="style-tutorial.html#toc2" REL=contents>
+</HEAD>
+<BODY>
+<A HREF="style-tutorial-3.html">Next</A>
+<A HREF="style-tutorial-1.html">Previous</A>
+<A HREF="style-tutorial.html#toc2">Contents</A>
+<HR>
+<H2><A NAME="s2">2. A Basic Introduction</A></H2>
+
+<P>This section incrementally introduces the most important aspects of
+the system. After reading this chapter you should be able to specify
+style files for
+about 80% of the commonly used indexes. The examples are demonstrated
+with a TeX markup so one can easily typeset the results <SF>xindy</SF>
+produces. You need LaTeX and the ISO-Latin enhancements that come
+with the <CODE>inputenc</CODE> package to run the following examples. Also the
+<SF>xindy</SF> system must already be installed.
+<P>
+But this tutorial doesn't reflect real life any more. The concepts are
+introduced below to explain them, but actual usage is probably
+different. In particular, you should not expect to specify sort rules
+by hand; usually one uses the language modules for that. Same way,
+xindy standard modules provide lots of markup functionality that you
+need for your documents, and can be used as a starting point.
+Nevertheless, let's continue with the explanation of <sf>xindy</sf>'s
+style file language.
+<P>
+<H2><A NAME="ss2.1">2.1 Running <SF>xindy</SF></A>
+</H2>
+
+<P>Create a new directory somewhere and copy some files from the
+distribution directory <CODE>doc/style-tutorial/</CODE> by typing
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+eg$ mkdir tutorial
+eg$ cd tutorial
+eg$ cp &lt;distrib-dir>/doc/style-tutorial/*.raw .
+eg$ cp &lt;distrib-dir>/doc/style-tutorial/*.tex .
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>with <CODE>distrib-dir</CODE> replaced by the actual location. Now create a
+file <CODE>style1.xdy</CODE> with the following content:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+;; This is a first example using `xindy'.
+
+(define-location-class "page-numbers" ("arabic-numbers"))
+(define-attributes (("definition" "usage")))
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Now run <SF>xindy</SF> by typing
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+eg$ xindy -t ex1.xlg -M style1 -I xindy ex1.raw
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>You should see something like
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+Opening logfile "ex1.xlg" (done)
+Reading indexstyle...
+Loading module "style1.xdy"...
+Finished loading module "style1.xdy".
+Finished reading indexstyle.
+Finalizing indexstyle... (done)
+
+Reading raw-index "ex1.raw"...
+Finished reading raw-index.
+
+Processing index... [10%] [20%] [30%] [40%] [50%] [60%] [70%] [80%] [90%] [100%]
+Finished processing index.
+
+Writing markup... [10%] [20%] [30%] [40%] [50%] [60%] [70%] [80%] [90%] [100%]
+Markup written into file "ex1.ind".
+</PRE>
+</CODE></BLOCKQUOTE>
+<P><SF>xindy</SF> has now successfully compiled the index <CODE>ex1.raw</CODE> using
+your index style <CODE>style1.xdy</CODE>. The result is now stored in file
+<CODE>ex1.ind</CODE>. You can view this file but currently it only contains an
+unreadable mix of data.
+<P>But now let's come back to our index style. The syntax of the command
+is in a Lisp-like form with lots of braces, looking a little bit
+weird, but you'll soon get used to it. What is the meaning of the two
+commands we specified? The first command informed <SF>xindy</SF> that we
+like to process page numbers. We do this by defining a new
+<EM>location class</EM> named <CODE>page-numbers</CODE>. The page numbers consist
+of <CODE>arabic-numbers</CODE> as we might expect but this is not necessarily
+true---imagine your page numbers consisted of roman numerals instead.
+When reading the <EM>raw index</EM> contained in file <CODE>ex1.raw</CODE>
+<SF>xindy</SF> checks all locations if they match all known location
+classes. Since in our example the only known location class is the
+class of page numbers which are written using arabic digits, all
+locations will be checked if they are correct page numbers.
+<P>The second command tells <SF>xindy</SF> that we use two types of
+attributes for location references. Most often the locations in an
+index denote different meanings. For example, in mathematical texts
+one will distinguish the <EM>definition</EM> of a mathematical term from
+its <EM>usage</EM>. Sometimes these are typeset using different font
+shapes such as <EM>italic</EM> or font series such as <B>boldface</B>. Each
+location has an associated attribute which, if it is unspecified,
+defaults to the attribute <CODE>default</CODE>. With this command you have
+made these attributes known to the system, which makes it possible to
+assign different markup to these attributes later on.
+<P>
+<P>
+<H2><A NAME="ss2.2">2.2 Adding some Markup</A>
+</H2>
+
+<P>Until now you haven't seen something exciting, so its time to specify
+some markup. Add the following lines to our index style:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(markup-index :open "~n\begin{theindex}~n"
+ :close "~n\end{theindex}~n"
+ :tree)
+
+(markup-locref :class "page-numbers" :attr "definition"
+ :open "{\bf " :close "}")
+
+(markup-locclass-list :open "\quad{}")
+(markup-locref-list :sep ", ")
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Now run <SF>xindy</SF> again and afterwards LaTeX:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+eg$ xindy -t ex1.xlg -M style1 -I xindy ex1.raw
+eg$ latex ex1.tex
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>You can view <CODE>ex1.dvi</CODE> with your prefered viewer (maybe <CODE>xdvi</CODE>
+or something else) to get a first impression of your results. Maybe
+your are not satisfied (for sure you aren't), because it still looks
+very confusing. What did the above rules tell <SF>xindy</SF>? When you
+view the file <CODE>ex1.ind</CODE> which is the result <SF>xindy</SF> generates,
+you'll recognize some of the <EM>markup tags</EM> you specified. The
+following is an excerpt of this file:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+\begin{theindex}
+ academia\quad{}{\bf 1}acafetado\quad{}{\bf 2}acalmar\quad{}{\bf 4}
+ açafrão\quad{}{\bf 3}indexflat\quad{}1hierarchical\quad{}2
+ veryhierarchical\quad{}3impressive\quad{}4saber\quad{}{\bf 7}
+ sabor\quad{}{\bf 8}sabão\quad{}{\bf 6}sábado\quad{}{\bf 5}
+\end{theindex}
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>First of all you'll see that the file starts with the string
+<CODE>\begin{theindex}</CODE> and ends with <CODE>\end{theindex}</CODE>.
+Additionally some locations are correctly enclosed into a TeX macro
+that typesets them in shape boldface, whereas others aren't. The
+boldface ones are all those locations from the raw index that have the
+attribute <CODE>definition</CODE>.
+<P>The <CODE>:open</CODE> and <CODE>:close</CODE> keyword arguments each take a string as
+argument. The first one is written to the file when <EM>opening</EM> an
+enviroment, whereas the latter one <EM>closes</EM> an environment. What we
+have specified is the markup for the whole index (which is actually
+printed only once) and the markup for all locations of class
+<CODE>page-numbers</CODE> which own the attribute <CODE>definition</CODE>. Here we
+have cleanly separated the structured markup from the visual one,
+allowing an easy redefinition if we decide, for example, to markup the
+<CODE>definition</CODE>-locations in italics instead of boldface.
+<P>Some words on <EM>keyword arguments</EM> and <EM>switches</EM>. Keyword
+arguments such as <CODE>:open</CODE> or <CODE>:close</CODE> always take exactly one
+argument which must be positioned right after the keyword separated by
+a whitespace (a blank or a tab-stop). Switches don't take any
+arguments. For example, <CODE>:tree</CODE> in the command <CODE>markup-index</CODE> is
+a switch and thus it does not take an argument. We will use this
+terminology throughout the rest of this document.
+<P>The third command caused <SF>xindy</SF> to insert a horizontal space
+between the keyword and the locations (the TeX command
+<CODE>\quad{}</CODE> simply inserts a specific horizontal space). The last
+command caused <SF>xindy</SF> to separate all location references from
+each other with a comma followed by a blank, independently of any
+location class.
+<P>As you already may have observed, the tilde sign (<CODE>~</CODE>) serves
+as a <EM>quoting character</EM>.
+<P>We continue specifying markup to get a printable result by adding more
+markup:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(markup-indexentry :open "~n \item " :depth 0)
+(markup-indexentry :open "~n \subitem " :depth 1)
+(markup-indexentry :open "~n \subsubitem " :depth 2)
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This assigns different markup for the different hierarchy layers of
+the indexentries. Our index is hierarchically organized. It contains
+items which themselves contain more sub-items which also might contain
+sub-sub-items. Each layer is started by a different markup which is
+correctly assigned with the <CODE>:depth</CODE> keyword argument. The layers
+are numbered by their <EM>depth</EM> starting from zero.
+<P>Now run <SF>xindy</SF> and TeX again and enjoy your first index. It's
+easy, isn't it! The output <CODE>ex1.ind</CODE> looks like the following:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+\begin{theindex}
+
+ \item academia\quad{}{\bf 1}
+ \item acafetado\quad{}{\bf 2}
+ \item acalmar\quad{}{\bf 4}
+ \item açafrão\quad{}{\bf 3}
+ \item index
+ \subitem flat\quad{}1
+ \subitem hierarchical\quad{}2
+ \subitem very
+ \subsubitem hierarchical\quad{}3
+ \subsubitem impressive\quad{}4
+ \item saber\quad{}{\bf 7}
+ \item sabor\quad{}{\bf 8}
+ \item sabão\quad{}{\bf 6}
+ \item sábado\quad{}{\bf 5}
+
+\end{theindex}
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>Hmm, as you might have seen there are several problems that need
+further investigation. The index contains some Portuguese words that
+are printed correctly but should appear at other positions inside the
+index. For instance, the word <EM>sábado</EM> should appear before the
+word <EM>saber</EM> since <EM>á</EM> must be sorted as if it were simply an
+<EM>a</EM>. The reason why these words are not sorted correctly is
+simple---the accentuated letters have codes beyond position 128 in the
+ISO-Latin alphabet. Sorting based on these codes yields this incorrect
+order.
+<P>What to do? We can define for each of the words containing these
+special characters an explicit <EM>print key</EM>. The print key describes
+the printed representation of the keyword whereas the <EM>key</EM> or
+<EM>main key</EM> is used for sorting and merging. A very tedious task
+which is not a very clever solution since in a non-english language
+many many words contain these special cases. We follow the way
+<SF>xindy</SF> offers: <EM>keyword-mappings</EM>.
+<P>
+<H2><A NAME="ss2.3">2.3 Keyword Mappings</A>
+</H2>
+
+<P>What are keyword mappings for? A good question. I'll try to give some
+answers.
+<P>
+<UL>
+<LI> <EM>Merging of differently written words</EM>. Some text formatting
+systems allow different writings for the same word. For example, TeX
+can be used with ISO-Latin characters as well as with its own
+character sequences. If a document is composed from smaller ones
+possibly written by different authors using different forms of writing
+the index entries, the same terms may happen to be written differently
+and consequently we need a mechanism to identify them as equal.
+</LI>
+<LI> <EM>Specifying the sort order</EM>. As outlined in the previous
+section it is really difficult and error-prone to specify the sort key
+for each keyword explicitly. Sometimes the sort order is even
+different for the type of the document, as it happens in German, where
+two different types of sortings exist, one for everyday indexes and
+one for dictionaries. The sort order actually defines the position of
+arbitrary language-specific letters inside of an index.
+</LI>
+</UL>
+<P>A detailed elaboration of these ideas can be found in the paper <EM>An
+International Version of MakeIndex</EM> by Joachim Schrod [3].
+It describes the ideas that led to modifications on one of the
+ancestors of the <SF>xindy</SF> system: <CODE>makeindex</CODE> [4].
+<P>The keyword mappings are as follows. The <EM>merge key</EM> is generated
+from the <EM>main key</EM> with the so called <EM>merge mapping</EM>. The
+merge mapping can be specified with the command <CODE>merge-rule</CODE>. The
+<EM>sort key</EM> is derived from the merge key using the <EM>sort
+mapping</EM> specified with the <CODE>sort-rule</CODE> command. The following
+scheme shows this mapping process:
+<P>
+<FIGURE>
+<EPS FILE="mappings.eps">
+<IMG SRC="mappings.gif">
+</FIGURE>
+<P>
+<P>We will use this command now to define a suitable sort mapping that
+fits our needs:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(sort-rule "à" "a")
+(sort-rule "á" "a")
+(sort-rule "ã" "a")
+(sort-rule "è" "e")
+(sort-rule "é" "e")
+(sort-rule "ç" "c")
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>These rules define mappings from a keyword to a <EM>normalized</EM>
+version. In the logfile <CODE>ex1.xlg</CODE> these transformations are logged so
+that one can see how these mappings are performed. In this example we
+do not need any <CODE>merge-rule</CODE> but we will see applications in
+further examples.
+<P>Running <SF>xindy</SF> and TeXing the result now places the indexentries
+at the right positions.
+<P>In reality, such sort rules tend to be much more complex, due to
+the idiosynchrasies of sorting natural languages. Sort rules for
+many languages are available as part of the xindy distribution, as
+so-called language modules. We specify the language with the option
+<code>-L</code>, e.g., in our example we could have used
+<BLOCKQUOTE><CODE>
+<PRE>
+eg$ xindy -t ex1.xlg -M style1 -L portuguese -I xindy ex1.raw
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>If we use one of the available language modules, sort rules in
+user-written xindy styles are ignored.
+<P>The result is now quite satisfying if the index entries weren't
+clumped together that much. We usually want the different index
+entries beginning with the same letter be optically separated from the
+ofhers. This improves readability and there must be a way to
+accomplish this---the <EM>letter groups</EM>.
+<P>
+<H2><A NAME="ss2.4">2.4 Letter Groups</A>
+</H2>
+
+<P>To group indexentries we must define what indexentries form a group.
+The clustering is done by matching the keywords' prefixes (taken from
+the <EM>sort key</EM>) with a user-defined table of prefixes and define
+appropriate markup that separates the groups from each other. Here it
+goes.
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(define-letter-groups
+ ("a" "b" "c" "d" "e" "f" "g" "h" "i" "j" "k" "l" "m"
+ "n" "o" "p" "q" "r" "s" "t" "u" "v" "w" "x" "y" "z"))
+
+(markup-letter-group-list :sep "~n\indexspace")
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This defines the given list of letter groups. When forming the letter
+groups, each letter group is checked if it matches a prefix of the
+indexentries' sort key. The longest match assigns the index entry to
+this letter group. If no match was possible the index entry is put into
+group <CODE>default</CODE>.
+<P>The result now looks much better than before. You have now learned the
+basic features that you need to specify everyday indexes. In the next
+chapter we'll continue to make you an expert in indexing.
+<P>
+<P>
+<HR>
+<A HREF="style-tutorial-3.html">Next</A>
+<A HREF="style-tutorial-1.html">Previous</A>
+<A HREF="style-tutorial.html#toc2">Contents</A>
+</BODY>
+</HTML>
diff --git a/Build/source/utils/xindy/doc/style-tutorial-3.html b/Build/source/utils/xindy/doc/style-tutorial-3.html
new file mode 100644
index 00000000000..5c598e54938
--- /dev/null
+++ b/Build/source/utils/xindy/doc/style-tutorial-3.html
@@ -0,0 +1,263 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <TITLE>XINDY Style File Tutorial: Advanced Features</TITLE>
+ <LINK HREF="style-tutorial-4.html" REL=next>
+ <LINK HREF="style-tutorial-2.html" REL=previous>
+ <LINK HREF="style-tutorial.html#toc3" REL=contents>
+</HEAD>
+<BODY>
+<A HREF="style-tutorial-4.html">Next</A>
+<A HREF="style-tutorial-2.html">Previous</A>
+<A HREF="style-tutorial.html#toc3">Contents</A>
+<HR>
+<H2><A NAME="s3">3. Advanced Features</A></H2>
+
+<P>In the following sections you'll learn more about the features of
+<SF>xindy</SF>. We'll show you how you can define your own
+location classes, specify the letter groups in more detail and bring
+you close to more specfic markup features. After reading this chapter
+you should be able to master about 95% of the commonly used indexes.
+<P>
+<P>
+<H2><A NAME="ss3.1">3.1 Location Classes</A>
+</H2>
+
+<P>We continue using a more complex index. Copy the current style to a
+new file (now <CODE>style2.xdy</CODE>) and run <SF>xindy</SF> on the raw index
+<CODE>ex2.raw</CODE> by typing:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+eg$ cp style1.xdy style2.xdy
+eg$ xindy -t ex2.xlg -M style2 -I xindy ex2.raw
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>You should see some error messages indicating that something is
+unknown to <SF>xindy</SF>. What has happend? The messages should be
+similar to the following snapshot:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+ ...
+WARNING:
+location-reference "B-5" did not match any location-class! (ignored)
+WARNING:
+location-reference "C-8" did not match any location-class! (ignored)
+WARNING:
+location-reference "iv" did not match any location-class! (ignored)
+WARNING:
+location-reference "ii" did not match any location-class! (ignored)
+ ...
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>The index contains new, and therefore unknown, location classes. The
+first one has an appendix-like style, whereas the second one seems to
+be lowercase roman numerals. <SF>xindy</SF> reported, that it doesn't know
+these locations and therefore knows nothing about their internal
+structure. We make them known to the system by adding the following
+commands to the style file.
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(define-location-class "roman-pages" ("roman-numerals-lowercase"))
+(define-location-class "appendices" ("ALPHA" :sep "-" "arabic-numbers"))
+(define-location-class-order ("roman-pages" "appendices"))
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>The first command tells <SF>xindy</SF> that there exist some page numbers
+that are written with roman lowercase letters. The second one defines
+the structure of the appendix locations. They consist of three
+elements, a capital letter, a separator---which is a hyphen in our
+case---and finally an arabic number. To be able to correctly
+distinguish separator strings from the names of the known
+<EM>basetypes</EM>, the argument <CODE>:sep</CODE> indicates, that the following
+is a separator. The last command simply says that the locations which
+are roman numerals shall appear before the appendix locations. So far
+we know three different basetypes. The built-in basetypes of
+<SF>xindy</SF> are:
+<P>
+<DL>
+<DT><B><CODE>arabic-numbers</CODE></B><DD><P>contains all non-negative numbers beginning
+with zero: 0, 1, 2, ....
+<P>
+<DT><B><CODE>roman-numerals-uppercase</CODE>, <CODE>roman-numerals-lowercase</CODE></B><DD><P>the
+roman numerals I, II, III, (IIII/IV), V, ... It contains the old and
+new roman numeral system. Two versions for uppercase and lowercase
+letters are supported.
+<P>
+<DT><B><CODE>ALPHA</CODE>, <CODE>alpha</CODE></B><DD><P>The US-ASCII alphabet letters (uppercase
+and lowercase letters).
+<P>
+<DT><B><CODE>digits</CODE></B><DD><P>the digits 0, 1, 2, 3, 4, 5, 6, 7, 8 and 9 in this
+order.
+</DL>
+<P>`Fine,', you'll say, `but what if my basetypes are completely
+different?' You're right! But <SF>xindy</SF> offers you to define your own
+alphabets. For example, you can define a new alphabet by writing
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(define-alphabet "my-personal-alphabet" ("Hi" "ho" "here" "I" "go"))
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This is a valid alphabet that consists of 5 <EM>letters</EM>. You can now
+define a location class
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(define-location-class "my-personal-class"
+ ("my-personal-alphabet" :sep "-" "arabic-numbers"))
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>to match all of the following locations: <EM>Hi-12, ho-2, here-709,
+I-9, go-42</EM>. <SF>xindy</SF> will recognize them and be able to sort them
+according to your specification which says that <EM>Hi</EM> comes before
+all others and <EM>here</EM> is exactly at the third position. So they
+will be sorted lexicographically, layer by layer, until it can decide
+which one is before or after the other. We have prepared a concrete
+example. Do you remember the example we gave when we spoke about
+indexing bible verses? This exactly matches the situation of such a
+self-defined alphabet which could look like the following definitions:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(define-alphabet "bible-chapters"
+ ("Genesis" "Exodus" "Leviticus" "Numbers" "Deuteronomy"
+ ... ))
+(define-location-class "bible-verses"
+ ("bible-chapters" :sep " " "arabic-numbers" :sep "," "arabic-numbers"))
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This description would match locations like <EM>Genesis 1,3</EM>,
+<EM>Exodus 7,8</EM>, etc.
+<P>Now run LaTeX on <CODE>ex2.tex</CODE> and view the results. It looks a
+little bit strange since <SF>xindy</SF> has automatically built ranges of
+successive locations. The first locations of the index entry <EM>roman</EM>
+actually denote the range <EM>ii</EM> until <EM>iv</EM>. <EM>Ranges</EM> consist
+of location references. To typeset them correctly you can specify
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(markup-range :sep "--")
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>This indicates that location reference forming a range shall be
+separated by a hyphen. Running <SF>xindy</SF> and LaTeX again gives a
+better idea of how it should look like. Here is a part of the
+generated output.
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+ ...
+ \item appendices\quad{}A-1, A-7, A-11, B-3--B-5, C-1, C-8, C-12,
+ C-13, C-22, D-2, D-3, D-5, D-10
+ ...
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>
+<H2><A NAME="ss3.2">3.2 Hierarchical Location Classes</A>
+</H2>
+
+<P>Somehow a lot of space is wasted when looking at the first index entry.
+Modify the definition of the location class for appendices as follows
+and add the other commands as well:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(define-location-class "appendices"
+ ("ALPHA" :sep "-" "arabic-numbers")
+ :hierdepth 2)
+(markup-locref-list :sep "; " :depth 0 :class "appendices")
+(markup-locref-list :open "~~" :sep ", " :depth 1 :class "appendices")
+</PRE>
+</CODE></BLOCKQUOTE>
+<P><EM>Note: Since the tilde character serves as our quoting character it
+must be quoted itself in the above example.</EM> Run <SF>xindy</SF> and view
+the output stored in <CODE>ex2.ind</CODE>. The output looks similar to the
+following:
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+ ...
+ \item appendices\quad{}A~1, 7, 11; B~3--5; C~1, 8, 12, 13, 22;
+ D~2, 3, 5, 10
+ ...
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>You can see that the location references of this class have been
+transformed into a hierarchical structure caused by the
+<CODE>:hierdepth</CODE> argument. Additionally we have specified markup for
+the layers of this class separately for the depths 0 and 1. The
+locations at depth 0 are separated by a `;' whereas the ones at depth
+1 are separated by a `,'.
+<P>Maybe you get an impression why we named <SF>xindy</SF> a <EM>flexible</EM>
+system.
+<P>
+<H2><A NAME="ss3.3">3.3 More about Letter Groups</A>
+</H2>
+
+<P>More problems arise when using languages with different letter
+schemes. Hungarian is an example. In Hungarian indexes the words
+beginning with the letters <EM>Cs, Ly, Ny</EM> and more are printed in a
+separate block. The words beginning with <EM>Ly</EM>, for example, appear
+behind the words beginning with an <EM>L</EM>. <SF>xindy</SF> allows to define
+this kind of letter groups as well. Add the following lines to the
+style file.
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+(define-letter-group "ly" :after "l" :before "m")
+(define-letter-group "ny" :after "n" :before "o")
+
+(markup-letter-group :open-head "~n {\bf " :close-head "}"
+ :capitalize)
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>The result looks like the following:
+<P>
+<P>
+<BLOCKQUOTE><CODE>
+<PRE>
+ ...
+ {\bf Ly}
+ \item lyuk\quad{}1
+ \item lyukas\quad{}2
+
+ \indexspace
+
+ {\bf M}
+ \item maga\quad{}1
+ \item magyar\quad{}2
+
+ \indexspace
+
+ {\bf N}
+ \item nagy\quad{}1
+ \item nagyon\quad{}9
+ \item nègy\quad{}4
+
+ \indexspace
+
+ {\bf Ny}
+ \item nyelv\quad{}1
+ \item nyolc\quad{}8
+ ...
+</PRE>
+</CODE></BLOCKQUOTE>
+<P>The result describes what the purpose of the above commands is. It
+becomes prettier from step to step, doesn't it?
+<P>You have now learned most of the features of <SF>xindy</SF>. Go playing
+around a little bit. For a detailed description of all commands and
+all their arguments and switches you should reference the manual that
+comes with this distribution.
+<P>
+<P>
+<P>
+<HR>
+<A HREF="style-tutorial-4.html">Next</A>
+<A HREF="style-tutorial-2.html">Previous</A>
+<A HREF="style-tutorial.html#toc3">Contents</A>
+</BODY>
+</HTML>
diff --git a/Build/source/utils/xindy/doc/style-tutorial-4.html b/Build/source/utils/xindy/doc/style-tutorial-4.html
new file mode 100644
index 00000000000..f3ef19aa4c8
--- /dev/null
+++ b/Build/source/utils/xindy/doc/style-tutorial-4.html
@@ -0,0 +1,41 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <TITLE>XINDY Style File Tutorial: References</TITLE>
+ <LINK HREF="style-tutorial-3.html" REL=previous>
+ <LINK HREF="style-tutorial.html#toc4" REL=contents>
+</HEAD>
+<BODY>
+Next
+<A HREF="style-tutorial-3.html">Previous</A>
+<A HREF="style-tutorial.html#toc4">Contents</A>
+<HR>
+<H2><A NAME="s4">4. References</A></H2>
+
+<P>
+<P>The following books and papers were referenced in this document.
+<P>
+<OL>
+<LI> D. E. Knuth, <EM>The TeXbook</EM>, Addison-Wesley, 1984
+</LI>
+<LI> Leslie Lamport, LaTeX <EM>A Document Preparation System</EM>,
+Addison-Wesley, 1986
+</LI>
+<LI> Joachim Schrod, <EM>An International Version of MakeIndex</EM>,
+Cahiers GUTenberg, 10, p81-90, 1991
+</LI>
+<LI> Pehong Chen and Michael A. Harrison, <EM>Automating Index
+Preparation</EM>, TR-87/347, University of California Berkeley, 1987
+<A NAME="makeindex"></A>
+</LI>
+<LI> Roger Kehr, <SF>xindy</SF>, <EM>Ein Flexibles Indexierungssystem</EM>,
+Studienarbeit FB Informatik, TH-Darmstadt, November 1995.</LI>
+</OL>
+<P>
+<HR>
+Next
+<A HREF="style-tutorial-3.html">Previous</A>
+<A HREF="style-tutorial.html#toc4">Contents</A>
+</BODY>
+</HTML>
diff --git a/Build/source/utils/xindy/doc/style-tutorial.html b/Build/source/utils/xindy/doc/style-tutorial.html
new file mode 100644
index 00000000000..6c815ca30d6
--- /dev/null
+++ b/Build/source/utils/xindy/doc/style-tutorial.html
@@ -0,0 +1,66 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
+<HTML>
+<HEAD>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
+ <TITLE>XINDY Style File Tutorial</TITLE>
+ <LINK HREF="style-tutorial-1.html" REL=next>
+
+
+</HEAD>
+<BODY>
+<A HREF="style-tutorial-1.html">Next</A>
+Previous
+Contents
+<HR>
+<H1>XINDY Style File Tutorial</H1>
+
+<H2><SF>A Flexible Indexing System</SF></H2>
+<H2>Roger Kehr</H2>
+<H3>Computer Science Department, Technical University of Darmstadt</H3>
+ and
+<H2>Joachim Schrod</H2>
+<H3>Joachim Schrod Net &amp; Publication Consultance GmbH</H3>
+Tutorial, Edition March 1997 for xindy version 1.1
+<P><HR>
+<EM> This is a tutorial on writing style files for
+the <SF>xindy</SF> indexing system
+[5]. <SF>xindy</SF> is a general purpose index processor that
+can be configured for a variety of document preparation systems. We
+will demonstrate step by step the incremental specification of a
+complete index style. The examples are based on indexes that are
+delivered with the system so one can get acquainted with it
+practically.
+<p>
+<B>Caution:</B> This tutorial does not describe the complete style file
+language. In particular, description of rule sets, the multi-run
+approach, and standard modules are missing.</EM>
+<HR>
+<P>
+<H2><A NAME="toc1">1.</A> <A HREF="style-tutorial-1.html">About <SF>xindy</SF></A></H2>
+
+<P>
+<H2><A NAME="toc2">2.</A> <A HREF="style-tutorial-2.html">A Basic Introduction</A></H2>
+
+<UL>
+<LI><A HREF="style-tutorial-2.html#ss2.1">2.1 Running <SF>xindy</SF></A>
+<LI><A HREF="style-tutorial-2.html#ss2.2">2.2 Adding some Markup</A>
+<LI><A HREF="style-tutorial-2.html#ss2.3">2.3 Keyword Mappings</A>
+<LI><A HREF="style-tutorial-2.html#ss2.4">2.4 Letter Groups</A>
+</UL>
+<P>
+<H2><A NAME="toc3">3.</A> <A HREF="style-tutorial-3.html">Advanced Features</A></H2>
+
+<UL>
+<LI><A HREF="style-tutorial-3.html#ss3.1">3.1 Location Classes</A>
+<LI><A HREF="style-tutorial-3.html#ss3.2">3.2 Hierarchical Location Classes</A>
+<LI><A HREF="style-tutorial-3.html#ss3.3">3.3 More about Letter Groups</A>
+</UL>
+<P>
+<H2><A NAME="toc4">4.</A> <A HREF="style-tutorial-4.html">References</A></H2>
+
+<HR>
+<A HREF="style-tutorial-1.html">Next</A>
+Previous
+Contents
+</BODY>
+</HTML>
diff --git a/Build/source/utils/xindy/doc/style-tutorial/Makefile.am b/Build/source/utils/xindy/doc/style-tutorial/Makefile.am
new file mode 100644
index 00000000000..20c1442b0c7
--- /dev/null
+++ b/Build/source/utils/xindy/doc/style-tutorial/Makefile.am
@@ -0,0 +1,38 @@
+## Use `autoreconf' in top-level directory to recreate all
+## autoconf/automake files.
+## Or, call `automake Makefile' to create only Makefile.in.
+
+## Copyright (C) 2004-2005 by Gour.
+##
+## This program is free software; you can redistribute it and/or
+## modify it under the terms of the GNU General Public License as
+## published by the Free Software Foundation; either version 2 of the
+## License, or (at your option) any later version.
+##
+## This program is distributed in the hope that it will be useful, but
+## WITHOUT ANY WARRANTY; without even the implied warranty of
+## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+## General Public License for more details.
+##
+## You should have received a copy of the GNU General Public License
+## along with this program in the file COPYING; if not, write to the
+## Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor,
+## Boston, MA 02110-1301 USA.
+
+docdir = $(datadir)/doc/$(PACKAGE_NAME)-$(PACKAGE_VERSION)
+
+tutorialdir = $(docdir)/style-tutorial
+
+FILES = \
+ ex1.raw \
+ ex1.tex \
+ ex2.raw \
+ ex2.tex \
+ index.tex \
+ style1.xdy \
+ style2.xdy
+
+EXTRA_DIST = $(FILES)
+
+tutorial_DATA = $(FILES)
+
diff --git a/Build/source/utils/xindy/doc/style-tutorial/Makefile.in b/Build/source/utils/xindy/doc/style-tutorial/Makefile.in
new file mode 100644
index 00000000000..b691dc713b8
--- /dev/null
+++ b/Build/source/utils/xindy/doc/style-tutorial/Makefile.in
@@ -0,0 +1,317 @@
+# Makefile.in generated by automake 1.9.6 from Makefile.am.
+# @configure_input@
+
+# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
+# 2003, 2004, 2005 Free Software Foundation, Inc.
+# This Makefile.in is free software; the Free Software Foundation
+# gives unlimited permission to copy and/or distribute it,
+# with or without modifications, as long as this notice is preserved.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
+# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
+# PARTICULAR PURPOSE.
+
+@SET_MAKE@
+
+srcdir = @srcdir@
+top_srcdir = @top_srcdir@
+VPATH = @srcdir@
+pkgdatadir = $(datadir)/@PACKAGE@
+pkglibdir = $(libdir)/@PACKAGE@
+pkgincludedir = $(includedir)/@PACKAGE@
+top_builddir = ../..
+am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd
+INSTALL = @INSTALL@
+install_sh_DATA = $(install_sh) -c -m 644
+install_sh_PROGRAM = $(install_sh) -c
+install_sh_SCRIPT = $(install_sh) -c
+INSTALL_HEADER = $(INSTALL_DATA)
+transform = $(program_transform_name)
+NORMAL_INSTALL = :
+PRE_INSTALL = :
+POST_INSTALL = :
+NORMAL_UNINSTALL = :
+PRE_UNINSTALL = :
+POST_UNINSTALL = :
+build_triplet = @build@
+host_triplet = @host@
+subdir = doc/style-tutorial
+DIST_COMMON = $(srcdir)/Makefile.in $(srcdir)/Makefile.am
+ACLOCAL_M4 = $(top_srcdir)/aclocal.m4
+am__aclocal_m4_deps = $(top_srcdir)/m4/ac_prog_latex.m4 \
+ $(top_srcdir)/m4/ac_prog_pdflatex.m4 \
+ $(top_srcdir)/configure.ac
+am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \
+ $(ACLOCAL_M4)
+mkinstalldirs = $(install_sh) -d
+CONFIG_CLEAN_FILES =
+SOURCES =
+am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`;
+am__vpath_adj = case $$p in \
+ $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \
+ *) f=$$p;; \
+ esac;
+am__strip_dir = `echo $$p | sed -e 's|^.*/||'`;
+am__installdirs = "$(DESTDIR)$(tutorialdir)"
+tutorialDATA_INSTALL = $(INSTALL_DATA)
+DATA = $(tutorial_DATA)
+ACLOCAL = @ACLOCAL@
+AMDEP_FALSE = @AMDEP_FALSE@
+AMDEP_TRUE = @AMDEP_TRUE@
+AMTAR = @AMTAR@
+AUTOCONF = @AUTOCONF@
+AUTOHEADER = @AUTOHEADER@
+AUTOMAKE = @AUTOMAKE@
+AWK = @AWK@
+BUILDDOCS_FALSE = @BUILDDOCS_FALSE@
+BUILDDOCS_TRUE = @BUILDDOCS_TRUE@
+BUILDRULES_FALSE = @BUILDRULES_FALSE@
+BUILDRULES_TRUE = @BUILDRULES_TRUE@
+CC = @CC@
+CCDEPMODE = @CCDEPMODE@
+CFLAGS = @CFLAGS@
+CLISP_DIR = @CLISP_DIR@
+CLISP_PATH = @CLISP_PATH@
+CPP = @CPP@
+CPPFLAGS = @CPPFLAGS@
+CXX = @CXX@
+CXXDEPMODE = @CXXDEPMODE@
+CXXFLAGS = @CXXFLAGS@
+CYGPATH_W = @CYGPATH_W@
+DEFS = @DEFS@
+DEPDIR = @DEPDIR@
+ECHO_C = @ECHO_C@
+ECHO_N = @ECHO_N@
+ECHO_T = @ECHO_T@
+EGREP = @EGREP@
+EXEEXT = @EXEEXT@
+EXT_CLISP_FALSE = @EXT_CLISP_FALSE@
+EXT_CLISP_TRUE = @EXT_CLISP_TRUE@
+INSTALL_DATA = @INSTALL_DATA@
+INSTALL_PROGRAM = @INSTALL_PROGRAM@
+INSTALL_SCRIPT = @INSTALL_SCRIPT@
+INSTALL_STRIP_PROGRAM = @INSTALL_STRIP_PROGRAM@
+LDFLAGS = @LDFLAGS@
+LEX = @LEX@
+LEXLIB = @LEXLIB@
+LEX_OUTPUT_ROOT = @LEX_OUTPUT_ROOT@
+LIBOBJS = @LIBOBJS@
+LIBS = @LIBS@
+LN_S = @LN_S@
+LTLIBOBJS = @LTLIBOBJS@
+MAKEINFO = @MAKEINFO@
+OBJEXT = @OBJEXT@
+PACKAGE = @PACKAGE@
+PACKAGE_BUGREPORT = @PACKAGE_BUGREPORT@
+PACKAGE_NAME = @PACKAGE_NAME@
+PACKAGE_STRING = @PACKAGE_STRING@
+PACKAGE_TARNAME = @PACKAGE_TARNAME@
+PACKAGE_VERSION = @PACKAGE_VERSION@
+PATH_SEPARATOR = @PATH_SEPARATOR@
+SET_MAKE = @SET_MAKE@
+SHELL = @SHELL@
+STRIP = @STRIP@
+VERSION = @VERSION@
+YACC = @YACC@
+ac_ct_CC = @ac_ct_CC@
+ac_ct_CXX = @ac_ct_CXX@
+ac_ct_STRIP = @ac_ct_STRIP@
+am__fastdepCC_FALSE = @am__fastdepCC_FALSE@
+am__fastdepCC_TRUE = @am__fastdepCC_TRUE@
+am__fastdepCXX_FALSE = @am__fastdepCXX_FALSE@
+am__fastdepCXX_TRUE = @am__fastdepCXX_TRUE@
+am__include = @am__include@
+am__leading_dot = @am__leading_dot@
+am__quote = @am__quote@
+am__tar = @am__tar@
+am__untar = @am__untar@
+bindir = @bindir@
+build = @build@
+build_alias = @build_alias@
+build_cpu = @build_cpu@
+build_os = @build_os@
+build_vendor = @build_vendor@
+datadir = @datadir@
+exec_prefix = @exec_prefix@
+host = @host@
+host_alias = @host_alias@
+host_cpu = @host_cpu@
+host_os = @host_os@
+host_vendor = @host_vendor@
+includedir = @includedir@
+infodir = @infodir@
+install_sh = @install_sh@
+latex = @latex@
+libdir = @libdir@
+libexecdir = @libexecdir@
+localstatedir = @localstatedir@
+mandir = @mandir@
+mkdir_p = @mkdir_p@
+oldincludedir = @oldincludedir@
+pdflatex = @pdflatex@
+prefix = @prefix@
+program_transform_name = @program_transform_name@
+sbindir = @sbindir@
+sharedstatedir = @sharedstatedir@
+sysconfdir = @sysconfdir@
+target_alias = @target_alias@
+docdir = $(datadir)/doc/$(PACKAGE_NAME)-$(PACKAGE_VERSION)
+tutorialdir = $(docdir)/style-tutorial
+FILES = \
+ ex1.raw \
+ ex1.tex \
+ ex2.raw \
+ ex2.tex \
+ index.tex \
+ style1.xdy \
+ style2.xdy
+
+EXTRA_DIST = $(FILES)
+tutorial_DATA = $(FILES)
+all: all-am
+
+.SUFFIXES:
+$(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(am__configure_deps)
+ @for dep in $?; do \
+ case '$(am__configure_deps)' in \
+ *$$dep*) \
+ cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh \
+ && exit 0; \
+ exit 1;; \
+ esac; \
+ done; \
+ echo ' cd $(top_srcdir) && $(AUTOMAKE) --foreign doc/style-tutorial/Makefile'; \
+ cd $(top_srcdir) && \
+ $(AUTOMAKE) --foreign doc/style-tutorial/Makefile
+.PRECIOUS: Makefile
+Makefile: $(srcdir)/Makefile.in $(top_builddir)/config.status
+ @case '$?' in \
+ *config.status*) \
+ cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh;; \
+ *) \
+ echo ' cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe)'; \
+ cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@ $(am__depfiles_maybe);; \
+ esac;
+
+$(top_builddir)/config.status: $(top_srcdir)/configure $(CONFIG_STATUS_DEPENDENCIES)
+ cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
+
+$(top_srcdir)/configure: $(am__configure_deps)
+ cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
+$(ACLOCAL_M4): $(am__aclocal_m4_deps)
+ cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
+uninstall-info-am:
+install-tutorialDATA: $(tutorial_DATA)
+ @$(NORMAL_INSTALL)
+ test -z "$(tutorialdir)" || $(mkdir_p) "$(DESTDIR)$(tutorialdir)"
+ @list='$(tutorial_DATA)'; for p in $$list; do \
+ if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \
+ f=$(am__strip_dir) \
+ echo " $(tutorialDATA_INSTALL) '$$d$$p' '$(DESTDIR)$(tutorialdir)/$$f'"; \
+ $(tutorialDATA_INSTALL) "$$d$$p" "$(DESTDIR)$(tutorialdir)/$$f"; \
+ done
+
+uninstall-tutorialDATA:
+ @$(NORMAL_UNINSTALL)
+ @list='$(tutorial_DATA)'; for p in $$list; do \
+ f=$(am__strip_dir) \
+ echo " rm -f '$(DESTDIR)$(tutorialdir)/$$f'"; \
+ rm -f "$(DESTDIR)$(tutorialdir)/$$f"; \
+ done
+tags: TAGS
+TAGS:
+
+ctags: CTAGS
+CTAGS:
+
+check-am: all-am
+check: check-am
+all-am: Makefile $(DATA)
+installdirs:
+ for dir in "$(DESTDIR)$(tutorialdir)"; do \
+ test -z "$$dir" || $(mkdir_p) "$$dir"; \
+ done
+install: install-am
+install-exec: install-exec-am
+install-data: install-data-am
+uninstall: uninstall-am
+
+install-am: all-am
+ @$(MAKE) $(AM_MAKEFLAGS) install-exec-am install-data-am
+
+installcheck: installcheck-am
+install-strip:
+ $(MAKE) $(AM_MAKEFLAGS) INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
+ install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)" INSTALL_STRIP_FLAG=-s \
+ `test -z '$(STRIP)' || \
+ echo "INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'"` install
+mostlyclean-generic:
+
+clean-generic:
+
+distclean-generic:
+ -test -z "$(CONFIG_CLEAN_FILES)" || rm -f $(CONFIG_CLEAN_FILES)
+
+maintainer-clean-generic:
+ @echo "This command is intended for maintainers to use"
+ @echo "it deletes files that may require special tools to rebuild."
+clean: clean-am
+
+clean-am: clean-generic mostlyclean-am
+
+distclean: distclean-am
+ -rm -f Makefile
+distclean-am: clean-am distclean-generic
+
+dvi: dvi-am
+
+dvi-am:
+
+html: html-am
+
+info: info-am
+
+info-am:
+
+install-data-am: install-tutorialDATA
+
+install-exec-am:
+
+install-info: install-info-am
+
+install-man:
+
+installcheck-am:
+
+maintainer-clean: maintainer-clean-am
+ -rm -f Makefile
+maintainer-clean-am: distclean-am maintainer-clean-generic
+
+mostlyclean: mostlyclean-am
+
+mostlyclean-am: mostlyclean-generic
+
+pdf: pdf-am
+
+pdf-am:
+
+ps: ps-am
+
+ps-am:
+
+uninstall-am: uninstall-info-am uninstall-tutorialDATA
+
+.PHONY: all all-am check check-am clean clean-generic distclean \
+ distclean-generic dvi dvi-am html html-am info info-am install \
+ install-am install-data install-data-am install-exec \
+ install-exec-am install-info install-info-am install-man \
+ install-strip install-tutorialDATA installcheck \
+ installcheck-am installdirs maintainer-clean \
+ maintainer-clean-generic mostlyclean mostlyclean-generic pdf \
+ pdf-am ps ps-am uninstall uninstall-am uninstall-info-am \
+ uninstall-tutorialDATA
+
+# Tell versions [3.59,3.63) of GNU make to not export all variables.
+# Otherwise a system limit (for SysV at least) may be exceeded.
+.NOEXPORT:
diff --git a/Build/source/utils/xindy/doc/style-tutorial/ex1.raw b/Build/source/utils/xindy/doc/style-tutorial/ex1.raw
new file mode 100644
index 00000000000..1f4585950a9
--- /dev/null
+++ b/Build/source/utils/xindy/doc/style-tutorial/ex1.raw
@@ -0,0 +1,20 @@
+;; Example raw-index file.
+
+(indexentry :key ("sábado") :locref "5" :attr "definition")
+(indexentry :key ("sabão") :locref "6" :attr "definition")
+(indexentry :key ("saber") :locref "7" :attr "definition")
+(indexentry :key ("sabor") :locref "8" :attr "definition")
+
+(indexentry :key ("academia") :locref "1" :attr "definition")
+(indexentry :key ("acafetado") :locref "2" :attr "definition")
+(indexentry :key ("açafrão") :locref "3" :attr "definition")
+(indexentry :key ("acalmar") :locref "4" :attr "definition")
+
+(indexentry :key ("index" "flat") :locref "1" :attr "usage")
+(indexentry :key ("index" "hierarchical") :locref "2" :attr "usage")
+(indexentry :key ("index" "very" "hierarchical") :locref "3" :attr "usage")
+(indexentry :key ("index" "very" "impressive") :locref "4" :attr "usage")
+
+;(indexentry :key ("arts" "classic") :locref "10" :attr "usage")
+;(indexentry :key ("arts" "contemporary") :locref "11" :attr "usage")
+;(indexentry :key ("arts" "modern") :locref "12" :attr "usage")
diff --git a/Build/source/utils/xindy/doc/style-tutorial/ex1.tex b/Build/source/utils/xindy/doc/style-tutorial/ex1.tex
new file mode 100644
index 00000000000..839c0b9834c
--- /dev/null
+++ b/Build/source/utils/xindy/doc/style-tutorial/ex1.tex
@@ -0,0 +1,16 @@
+%%
+%% An sample file for typesetting an index.
+%%
+
+\documentclass[12pt]{article}
+
+\usepackage[latin1]{inputenc}
+\usepackage{makeidx}
+
+\makeindex
+
+\begin{document}
+
+\printindex
+
+\end{document}
diff --git a/Build/source/utils/xindy/doc/style-tutorial/ex2.raw b/Build/source/utils/xindy/doc/style-tutorial/ex2.raw
new file mode 100644
index 00000000000..88b767aa60f
--- /dev/null
+++ b/Build/source/utils/xindy/doc/style-tutorial/ex2.raw
@@ -0,0 +1,35 @@
+;; Example raw-index file.
+
+(indexentry :key ("appendices") :locref "A-1" :attr "usage")
+(indexentry :key ("appendices") :locref "A-7" :attr "usage")
+(indexentry :key ("appendices") :locref "A-11" :attr "usage")
+(indexentry :key ("appendices") :locref "B-3" :attr "usage")
+(indexentry :key ("appendices") :locref "B-4" :attr "usage")
+(indexentry :key ("appendices") :locref "B-5" :attr "usage")
+(indexentry :key ("appendices") :locref "C-8" :attr "usage")
+(indexentry :key ("appendices") :locref "C-12" :attr "usage")
+(indexentry :key ("appendices") :locref "C-13" :attr "usage")
+(indexentry :key ("appendices") :locref "C-22" :attr "usage")
+(indexentry :key ("appendices") :locref "C-1" :attr "usage")
+(indexentry :key ("appendices") :locref "D-2" :attr "usage")
+(indexentry :key ("appendices") :locref "D-3" :attr "usage")
+(indexentry :key ("appendices") :locref "D-5" :attr "usage")
+(indexentry :key ("appendices") :locref "D-10" :attr "usage")
+
+(indexentry :key ("roman") :locref "iv" :attr "usage")
+(indexentry :key ("roman") :locref "ii" :attr "usage")
+(indexentry :key ("roman") :locref "iii" :attr "usage")
+(indexentry :key ("roman") :locref "ix" :attr "usage")
+(indexentry :key ("roman") :locref "x" :attr "usage")
+(indexentry :key ("roman") :locref "mcmxcvi" :attr "usage")
+
+(indexentry :key ("lyuk") :locref "1" :attr "usage")
+(indexentry :key ("lyukas") :locref "2" :attr "usage")
+(indexentry :key ("maga") :locref "1" :attr "usage")
+(indexentry :key ("magyar") :locref "2" :attr "usage")
+(indexentry :key ("nagy") :locref "1" :attr "usage")
+(indexentry :key ("nagyon") :locref "9" :attr "usage")
+(indexentry :key ("negy") :locref "4" :attr "usage")
+(indexentry :key ("nyolc") :locref "8" :attr "usage")
+(indexentry :key ("nyelv") :locref "1" :attr "usage")
+
diff --git a/Build/source/utils/xindy/doc/style-tutorial/ex2.tex b/Build/source/utils/xindy/doc/style-tutorial/ex2.tex
new file mode 100644
index 00000000000..839c0b9834c
--- /dev/null
+++ b/Build/source/utils/xindy/doc/style-tutorial/ex2.tex
@@ -0,0 +1,16 @@
+%%
+%% An sample file for typesetting an index.
+%%
+
+\documentclass[12pt]{article}
+
+\usepackage[latin1]{inputenc}
+\usepackage{makeidx}
+
+\makeindex
+
+\begin{document}
+
+\printindex
+
+\end{document}
diff --git a/Build/source/utils/xindy/doc/style-tutorial/index.tex b/Build/source/utils/xindy/doc/style-tutorial/index.tex
new file mode 100644
index 00000000000..839c0b9834c
--- /dev/null
+++ b/Build/source/utils/xindy/doc/style-tutorial/index.tex
@@ -0,0 +1,16 @@
+%%
+%% An sample file for typesetting an index.
+%%
+
+\documentclass[12pt]{article}
+
+\usepackage[latin1]{inputenc}
+\usepackage{makeidx}
+
+\makeindex
+
+\begin{document}
+
+\printindex
+
+\end{document}
diff --git a/Build/source/utils/xindy/doc/style-tutorial/style1.xdy b/Build/source/utils/xindy/doc/style-tutorial/style1.xdy
new file mode 100644
index 00000000000..ee809f9aae8
--- /dev/null
+++ b/Build/source/utils/xindy/doc/style-tutorial/style1.xdy
@@ -0,0 +1,55 @@
+;; This is a first example using `xindy'.
+
+(mapc #'(lambda (x)
+ (pushnew x *features*))
+ '(:STEP1 :STEP2 :STEP3 :STEP4 :STEP5))
+
+#+:STEP1
+(progn
+ (define-location-class "page-numbers" ("arabic-numbers"))
+ (define-attributes (("definition" "usage")))
+ )
+
+
+#+:STEP2
+(progn
+ (markup-index :open "~n\begin{theindex}~n"
+ :close "~n~n\end{theindex}~n"
+ :tree)
+
+ (markup-locref :class "page-numbers" :attr "definition"
+ :open "{\bf " :close "}")
+
+ (markup-locref-list :sep ", ")
+ (markup-locclass-list :open "\quad{}")
+ )
+
+#+:STEP3
+(progn
+ (markup-indexentry :open "~n \item " :depth 0)
+ (markup-indexentry :open "~n \subitem " :depth 1)
+ (markup-indexentry :open "~n \subsubitem " :depth 2)
+
+ (markup-range :class "page-numbers" :sep "--")
+ )
+
+#+:STEP4
+(progn
+ (sort-rule "à" "a")
+ (sort-rule "á" "a")
+ (sort-rule "ã" "a")
+ (sort-rule "è" "e")
+ (sort-rule "é" "e")
+ (sort-rule "ç" "c")
+
+ (sort-rule "\\texttt{\(.*\)}" "\1" :again :bregexp)
+ )
+
+#+:STEP5
+(progn
+ (define-letter-groups
+ ("a" "b" "c" "d" "e" "f" "g" "h" "i" "j" "k" "l" "m"
+ "n" "o" "p" "q" "r" "s" "t" "u" "v" "w" "x" "y" "z"))
+
+ (markup-letter-group-list :sep "~n~n \indexspace~n")
+ )
diff --git a/Build/source/utils/xindy/doc/style-tutorial/style2.xdy b/Build/source/utils/xindy/doc/style-tutorial/style2.xdy
new file mode 100644
index 00000000000..e45e2f24482
--- /dev/null
+++ b/Build/source/utils/xindy/doc/style-tutorial/style2.xdy
@@ -0,0 +1,80 @@
+;; This is another example using `xindy'.
+
+(mapc #'(lambda (x)
+ (pushnew x *features*))
+ '(:STEP1 :STEP2 :STEP3 :STEP4 :STEP5 :STEP6 :STEP7 :STEP8 :STEP9 :STEP10))
+
+#+:STEP1
+(progn
+ (define-location-class "page-numbers" ("arabic-numbers"))
+ (define-attributes (("definition" "usage")))
+ )
+
+
+#+:STEP2
+(progn
+ (markup-index :open "~n\begin{theindex}~n"
+ :close "~n~n\end{theindex}~n"
+ :tree)
+
+ (markup-locref :class "page-numbers" :attr "definition"
+ :open "{\bf " :close "}")
+
+ (markup-locref-list :sep ", ")
+ (markup-locclass-list :open "\quad{}")
+ )
+
+#+:STEP3
+(progn
+ (markup-indexentry :open "~n \item " :depth 0)
+ (markup-indexentry :open "~n \subitem " :depth 1)
+ (markup-indexentry :open "~n \subsubitem " :depth 2)
+ )
+
+#+:STEP4
+(progn
+ (sort-rule "à" "a")
+ (sort-rule "á" "a")
+ (sort-rule "ã" "a")
+ (sort-rule "è" "e")
+ (sort-rule "é" "e")
+ (sort-rule "ç" "c")
+
+ (sort-rule "\\texttt{(.*)}" "\1" :again :bregexp)
+ )
+
+#+:STEP5
+(progn
+ (define-letter-groups
+ ("a" "b" "c" "d" "e" "f" "g" "h" "i" "j" "k" "l" "m"
+ "n" "o" "p" "q" "r" "s" "t" "u" "v" "w" "x" "y" "z"))
+
+ (markup-letter-group-list :sep "~n~n \indexspace~n")
+ )
+
+#+:STEP6
+(progn
+ (define-location-class "roman-pages" ("roman-numbers-lowercase"))
+ #-:STEP8
+ (define-location-class "appendices" ("ALPHA" :sep "-" "arabic-numbers"))
+ )
+
+#+:STEP7
+(markup-range :sep "--")
+
+#+:STEP8
+(progn
+ (define-location-class "appendices" ("ALPHA" :sep "-" "arabic-numbers")
+ :hierdepth 2)
+ (markup-locref-list :sep "; " :depth 0 :class "appendices")
+ (markup-locref-list :open "~~" :sep ", " :depth 1 :class "appendices")
+ )
+
+#+:STEP9
+(progn
+ (define-letter-group "ly" :after "l" :before "m")
+ (define-letter-group "ny" :after "n" :before "o")
+
+ (markup-letter-group :open-head "~n {\bf " :close-head "}"
+ :capitalize)
+ )
diff --git a/Build/source/utils/xindy/doc/tex2xindy.pdf b/Build/source/utils/xindy/doc/tex2xindy.pdf
new file mode 100644
index 00000000000..65b834d225d
--- /dev/null
+++ b/Build/source/utils/xindy/doc/tex2xindy.pdf
Binary files differ
diff --git a/Build/source/utils/xindy/doc/texindy.pdf b/Build/source/utils/xindy/doc/texindy.pdf
new file mode 100644
index 00000000000..0d460cc060f
--- /dev/null
+++ b/Build/source/utils/xindy/doc/texindy.pdf
Binary files differ
diff --git a/Build/source/utils/xindy/doc/toc.gif b/Build/source/utils/xindy/doc/toc.gif
new file mode 100644
index 00000000000..3d1aebf3274
--- /dev/null
+++ b/Build/source/utils/xindy/doc/toc.gif
Binary files differ
diff --git a/Build/source/utils/xindy/doc/xindy.pdf b/Build/source/utils/xindy/doc/xindy.pdf
new file mode 100644
index 00000000000..f861491dfb8
--- /dev/null
+++ b/Build/source/utils/xindy/doc/xindy.pdf
Binary files differ
diff --git a/Build/source/utils/xindy/doc/xindy.v2.pdf b/Build/source/utils/xindy/doc/xindy.v2.pdf
new file mode 100644
index 00000000000..121f47982e4
--- /dev/null
+++ b/Build/source/utils/xindy/doc/xindy.v2.pdf
Binary files differ