next_inactive up previous

Aspell Devel Docs

Copyright (c) 2002
Kevin Atkinson



This manual is designed for those who which to developer Aspell. It is currently very sketchy. However, it should improve over time. The latest version of this document can be found at

The eventual goal is to convert this manual into Texinfo. However, since I do not have the time to learn Texinfo right now, I decided to use something I am already conferable with. Once someone goes through the trouble of converting it into Texinfo I will maintain the Texinfo version.


Copyright (c) 2002 Kevin Atkinson. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts. and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

1 Style Guidelines

As far as coding styles go I am really not that picky. The important thing is to stay consistent. However, please what ever you do, do not indent with more than 4 characters as I find indenting with more than that extremely difficult to read as most of the code ends up on the right side of the window.

2 C++ Standard Library

The C++ Standard library is not used directly except under very specific circumstances. The string class and the STL is used indirectly though wrapper classes and all I/O is done using the standard C library with light right helper classes to make using C I/O a bit more C++ like.

However the new, new[], delete and delete[] operates are used to allocated memory when appropriate.

3 Templates

Templates are used in Aspell when there is a clear advantage to doing so. When ever you use templates please use them carefully and try very hard not to create code bloat by generating a lot of unnecessary, and duplicate code.

4 Error Handling

Exceptions are not used in Aspell as I find them more trouble than they are worth. Instead an alternate method of error handling is used which is based around the PosibErr class. PosibErr is a special Error handling device that will make sure that an error is properly handled. It is defined in ``posib_err.hpp''. PosibErr is expected to be used as the return type of the function It will automatically convert to the "normal" return type however if the normal returned type is accessed and there is an "unhandled" error condition it will abort It will also abort if the object is destroyed with an "unhandled" error condition. This includes ignoring the return type of a function returning an error condition. An error condition is handled by simply checking for the presence of an error, calling ignore, or taking ownership of the error.

The PosibErr class is used extensively though out Aspell. Please refer to the Aspell source for examples of using PosibErr until better documentation is written.

5 Source Code Layout

Common code used by all parts of Aspell
Library code used only by the actual Aspell library
Data files used by Aspell
Aspell modules which are eventually meant to be pluggable


Main speller Module.
Scripts and data files to automatically generate code used by Aspell
Header files and such that external programs should use when in order to use the Aspell library.

The external ``C'' interface that programs should be using when they wish to use Aspell.
Actual programs based on the Aspell library. The main ``aspell'' utility is included here.
Misc. scripts used by Aspell
Example programs demonstrating the use of the Aspell library

6 Strings

6.1 String

The String class provided the same functionally of the C++ string except for fewer constructors. It also inherits OStream so that you can write to it with the ``<<'' operator. It is defined in ``string.hpp''.

6.2 ParmString

ParmString is a special string class that is designed to be used as a parameter for a function that is expecting a string. It is defined in ``parm_sting.hpp''. It will allow either a "const char *" or "String" class to be passed in. It will automatically convert to a "const char *". The string can also be accesses via the "str" method. Usage example:

void foo(ParmString s1, ParmString s2) { 
   const char * str0 = s1; 
   unsigned int size0 = s2.size() 
   if (s1 == s2 || s2 == "bar") { 

String s1 = "..."; 
const char * s2 = "..."; 
This class should be used when a string is being passed in as a parameter. It is faster than using ``const String SPMamp;'' (as that will create an unnecessary temporary when a const char * is passed in), and is less annoying than using ``const char *'' (as it doesn't require the c_str() method to be used when a String is passed in).

6.3 CharVector

A character vector is basically a Vector<char> but it has a few additional methods for dealing with strings which Vector does not provide. It, like String, is also inherits OStream so that you can write to it with the ``<<'' operator. It is defined in ``char_vector.hpp''. Use it when ever you need a string which is guaranteed to be in a continuous block of memory which you can write to.

7 Smart Pointers

Smart pointers are used extensively in Aspell to avoid simplify memory management tasks and to avoid memory leaks.

7.1 CopyPtr

The CopyPtr class makes a deep copy of an object when ever it is copied. The CopyPtr class is defined in ``copy_ptr.hpp''. This header should be included where ever CopyPtr is used. The complete definition of the object CopyPtr is pointing to does not need to be defined at this point. The implementation is defined in ``copy_ptr-t.hpp''. The implementation header file should be included at a point in your code where the class CopyPtr is pointing to is completely defined.

7.2 ClonePtr

ClonePtr is like copy pointer except the clone() method is used instead of the copy constructor to make copies of an object. If is defined in ``clone_ptr.hpp'' and implemented in ``clone_ptr-t.hpp''.

7.3 StackPtr

A StackPtr is designed to be used when ever the only pointer to a new object allocated with new is on the stack. It is similar to the standard C++ auto_ptr but the semantics are a bit different. It is defined in ``stack_ptr.hpp'' unlike CopyPtr of ClonePtr it is defined and implemented in this header file.

7.4 GenericCopyPtr

A generalized version of CopyPtr and ClonePtr which the two are based on. It is defined in ``generic_copy_ptr.hpp'' and implemented in ``generic_copy_ptr-t.hpp''.

8 I/O

Aspell does not use C++ I/O classes and function in any way since they do not provide a way to get at the underlying file number and can often be slower than the highly tuned C I/O functions found in the standard C library. However, some light weight wrapper classes are provided so that standard C I/O can be used in a more C++ like way.

8.1 IStream/OStream

These two base classes mimic some of the functionally of the C++ functionally of the corresponding classes. They are defined in ``istream.hpp'' and ``ostream.hpp'' respectfully. They are however based on standard C I/O and are not proper C++ streams.

8.2 FStream

Defined in ``fstream.hpp''

8.3 Standard Streams

CIN/COUT/CERR. Defined in ``iostream.hpp''.

9 Config Class

The Config class is used to hold configuration information. It has a set of keys which it will except. Inserting or even trying to look at a key that it does not know will produce an error. It is defined in ``common/config.hpp''

10 Filter Interface

10.1 Overview

In Aspell there are 5 types of filters:

  1. Decoders which take input in some standard format such as iso8859-1 or UTF-8 and convert it into a string of FilterChars.
  2. Decoding filters which manipulates a string of FilterChars by decoding the text is some way such as converting SGML character into its Unicode value.
  3. True filters which manipulates a string of FilterChars to make it more suitable for spell checking. These filers generally blank out text which should not be spell checked
  4. Encoding filters which manipulates a string of FilterChars by encoding the text is some way such as converting certain Unicode characters to SGML characters.
  5. Encoders which take a string of FilterChars and convert into a standard format such as iso8859-1 or UTF-8
Which types of filters are used depends on the situation

  1. When decoding words for spell checking:

  1. When encoding words such as those returned for suggestions:

A FilterChar is a struct defined in ``common/filter_char.hpp'' which contains two members, a character, and a width. Its purpose is to keep track of the width of the character in the original format. This is important because when a misspelled word is found the exact location of the word needs to be returned to the application so that it can highlight it for the user. For example if the filters translated this:

Mr. foo said &quot;I hate my namme&quot;.
to this

Mr. foo said "I hate my namme".
without keeping track of the original width of the characters the application will likely highlight ``e my '' as the misspelling because the spell checker will return 25 as the offset instead of 30. However with keeping track of the width using FilterChar the spell checker will now that the real position it 30 since the quote is really 6 characters wide. In particular the text will be annotated something like the following:

Mr. foo said "I hate my namme".
The standard encoder and decoder filters are defined in ``common/convert.cpp''. There should generally not be any need to deal with them so they will not be discussed here. The other three filters, the encoding filter, the true filter, and the decoding filter, are all defined the exact same way; they are inherited from the IndividualFilter class.

10.2 Adding a New Filter

To add a new filter create a new file in the modules/filter directory, the file should be a C++ file and end in ``.cpp''. The file should contain a new filter class inherited from IndividualFilter, a function to return a new filter, and an optional KeyInfo array for adding options to control the behavior of the filter. The file then needs to be added to so that the build system knows about the filter and lib/new_filter.cpp must be modified so that Aspell knows about the filter.

10.3 IndividualFilter class

All filters are required to inherit from the IndividualFilter class found in ``indiv_filter.hpp''. See that file for more details and the other filter modules for examples of how it is used.

10.4 Constructor Function

After the class is created a function must to created which will return a new filter allocated with new. The function must have the following prototype:

IndividualFilter * new_«filter_name»
Filters are defined in groups where each group contains an encoding filter, a true filter, and a decoding filter. Only one of them is required to be defined, however they all need a separate constructor function.

10.5 Config Options

A filter group may have any number of options associated with it as long as they all start with the filter name. See the TEX and SGML filter for examples of what to do and ``config.hpp'' for the definition of the KeyInfo struct.

10.6 Makefile Modifications

After the new file is created simply add the file to the ``libaspell_filter_standard_la_SOURCES'' line in ``modules/filter/'' so that the build system knows about it.

10.7 New_filter Modifications

Finally modify ``lib/new_filter.cpp'' so that Aspell knows about the new filter. Follow the example there for the other filter modules. The filter_modules array should only be modified if there your filter has config options.

11 Data Structures

When ever possible you should try to use on of the data structures available. If the data structures do not provide enough functionally for your needs you should consider enhancing them rather than written something from scratch.

11.1 Vector

The vector class is defined in ``vector.hpp'' and works the same way as the standard STL vector does except that it doesn't have as many constructors.

11.2 BasicList

BasicList is a simple list structure which can either be implemented as a singly or doubly linked list. It is defined in ``basic_list.hpp''.

11.3 StringMap

StringMap is a associative array for strings. You should try to use this when ever possible to avoid code bloat. It is defined in ``string_map.hpp''

11.4 Hash Tables

Several hash tables are provided when StringMap is not appropriate. These hash tables provide a hash_set, hash_multiset, hash_map and hash_multimap which are very similar to SGI STL's implementation with a few exceptions. It is defined in ``hash.hpp''

11.5 BlockSList

BlockSList provided a pool of nodes which can be used for singly linked lists. It is defined in ``block_slist.hpp''.

12 Mk-Src Script

A good deal of interface code is automatically generated by the ``'' Perl script. I am doing it this way to avoid having to write a lot of relative code for the C++ interface. This should also make adding interface for other languages a lot less tedious and will allow the interface to automatically take advantage of new Aspell functionality as it is made available. The ``'' script uses ``'' as its input.


The format of is as follows:

  The following charaters are literals: { } / '\ ' \n = >
  <items> := (<item>\n)+
  <items> := <category>:\ <name> {\n<details>\n} | <<tab>><details>
  <details> := <options>\n /\n <items>
  <options> := (<option>\n)*
  <option> := <key> [=> <value>]
  <<tab>> means everything should be indented by one tab

See MkSrc::Info for a description of the categorys and options

12.2 MkSrc::Info


The info array contains information on how to process the info in It has the following layout

   <catagory> => options => [] 
                 groups => [] # if undef than anything is accepted
                 creates_type => "" # the object will create a new type
                                    # as specified
                 proc => <impl type> => sub {}

where <impl type> is one of:

  cc: for "aspell.h" header file
  cxx: for C++ interface implemented on top of cc interface
  native: for creation of header files used internally by aspell
  impl: for defination of functions declared in cc interface.
        the definations use the native hedaer files
  native_impl: for implementations of stuff declared in the native
                header files

each proc sub should take the following argv

   $data: a subtree of $master_data

<options> is one of:

  desc: description of the object
  posib err: the method may return an error condition
  c func:
  const: the method is a const member
  c only: only include in the external interface
  c impl headers: extra headers that need to be included in the C impl
  c impl: use this as the c impl instead of the default
  cxx impl: use this as the cxx impl instead of the default
  returns alt type: the constructor returns some type other than
    the object from which it is a member of
  no native: do not attemt to create a native implementation
  treat as object: treat as a object rather than a pointer

The %info structure is initialized as follows:

 our %info =
  root => { 
    options => [],
    groups => ['methods', 'group']},
  methods => {
    # methods is a collection of methods which will be inserted into
    # a class after some simple substation rules.  A $ will be
    # replaced with name of the class.
    options => ['strip', 'prefix', 'c impl headers'],
    groups => undef},
  group => {
    # a group is a colection of objects which should be grouped together
    # this generally means they will be in the same source file
    options => ['no native'],
    groups => ['enum', 'struct', 'union', 'func', 'class', 'errors']},
  enum => {
    # basic C enum
    options => ['desc', 'prefix'],
    creates_type => 'enum'},
  struct => {
    # basic c struct
    options => ['desc', 'treat as object'],
    groups => undef,
    creates_type => 'struct',},
  union => {
    # basic C union
    options => ['desc', 'treat as object'],
    groups => undef,
    creates_type => 'union'},
  class => {
    # C++ class
    options => ['c impl headers'],
    groups => undef,
    creates_type => 'class'},
  errors => {}, # possible errors
  method => {
    # A class method
    options => ['desc', 'posib err', 'c func', 'const',
                'c only', 'c impl', 'cxx impl'],
    groups => undef},
  constructor => {
    # A class constructor
    options => ['returns alt type', 'c impl', 'desc'],
    groups => 'types'},
  destructor => {
    # A class destructor
    options => [],
    groups => undef},

In addition to the categories listed above a "methods" catagory by be specified in under the class category. A "methods" catagory is created for each methods group under the name "<methods name> methods" When groups is undefined a type name may be specified in place of a category


types contains a master list of all types. This includes basic types and ones created in The basic types include:

     'void', 'bool', 'pointer', 'double',
     'string', 'encoded string', 'string obj',
     'char', 'unsigned char',
     'short', 'unsigned short',
     'int', 'unsigned int',
     'long', 'unsigned long'


%methods is used for holding the "methods" information

12.3 MkSrc::Util

This module contains various useful utility functions:


Returns 0.


Returns 1.


Apply EXPR to each item in LIST and than concatenate the result into a string

one_of STR LIST

Returns true if LIST contains at least one of STR.

to_upper STR

Convert STR to all uppercase and substitute spaces with underscores.

to_lower STR

Convert STR to all lowercase and substitute spaces with underscores.

to_mixed STR

Convert STR to mixed case where each new word startes with a uppercase letter. For example "feed me" would become "FeedMe".

12.4 MkSrc::Read


Read in "" and returns a data structure which has the following format:

    <tree> := <options>
              data => <tree>
  where each tree represents an entry in  
  The following two options are always provided:
    name: the name of the entry
    type: the catagory or type name
  Additional options are the same as specified in %info

12.5 MKSrc::Create

create_cc_file PARMS

Create a source file.

  Required Parms: type, dir, name, data
   Boolean Parms: header, cxx
  Optional Parms: namespace (required if cxx), pre_ext, accum

create_file FILENAME DATA

Writes DATA to FILENAME but only if DATA differs from the content of the file and the string:

    Automatically generated file.

is present in the existing file if it already exists.

12.6 Code Generation Modes

The code generation modes are currently one of the following:

  cc: Mode used to create types suitable for C interface
  cc_cxx: Like cc but typenames don't have a leading Aspell prefix
  cxx: Mode used to create types suitable for CXX interface
  native: Mode in which types are suitable for the internal implementation
  native_no_err: Like Native but with out PosibErr return types

12.7 MkSrc::CcHelper

Helper functions used by interface generation code:

to_c_return_type ITEM


c_error_cond ITEM



Creates a function prototype

Parms can be any of:

  mode: code generation mode


Return a string to call a func. Will prefix the function with return if the functions returns a non-void type;

Parms can be any of:

  mode: code generation mode

to_type_name ITEM PARMS ; %ACCUM

Converts item into a type name.

Parms can be any of:

  mode: code generation mode
  use_type: include the actual type
  use_name: include the name on the type
  pos: either "return" or "other"

make_desc DESC ; LEVEL

Make a C comment out of DESC optionally indenting it LEVEL spaces.

make_c_method CLASS ITEM PARMS ; %ACCUM

Create the phototype for a C method which is really a function.

Parms is any of:

  mode: code generation mode
  no_aspell: if true do not include aspell in the name
  this_name: name for the paramater representing the current object

call_c_method CLASS ITEM PARMS ; %ACCUM

Like make_c_method but instead returns the appropriate string to call the function. If the function returns a non-void type the string will be prefixed with a return statement.

form_c_method CLASS ITEM PARMS ; %ACCUM

Like make_c_method except that it returns the array:

  ($func, $data, $parms, $accum)

which is suitable for passing into make_func. It will return an empty array if it can not make a method from ITEM.

make_cxx_method ITEM PARMS ; %ACCUM

Create the phototype for a C++ method.

Parms is one of:

  mode: code generation mode

13 GNU Free Documentation License

Version 1.1, March 2000

Copyright © 2000 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.


The purpose of this License is to make a manual, textbook, or other written document ``free'' in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.

This License is a kind of ``copyleft'', which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.

We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

13.1 Applicability and Definitions

This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The ``Document'', below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as ``you''.

A ``Modified Version'' of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.

A ``Secondary Section'' is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.

The ``Invariant Sections'' are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.

The ``Cover Texts'' are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License.

A ``Transparent'' copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not ``Transparent'' is called ``Opaque''.

Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LATEX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only.

The ``Title Page'' means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, ``Title Page'' means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.

13.2 Verbatim Copying

You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.

You may also lend copies, under the same conditions stated above, and you may publicly display copies.

13.3 Copying in Quantity

If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.

If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.

If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.

It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

13.4 Modifications

You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.

You may add a section entitled ``Endorsements'', provided it contains nothing but endorsements of your Modified Version by various parties - for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.

You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.

The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

13.5 Combining Documents

You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice.

The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.

In the combination, you must combine any sections entitled ``History'' in the various original documents, forming one section entitled ``History''; likewise combine any sections entitled ``Acknowledgements'', and any sections entitled ``Dedications''. You must delete all sections entitled ``Endorsements.''

13.6 Collections of Documents

You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.

You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

13.7 Aggregation With Independent Works

A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an ``aggregate'', and this License does not apply to the other self-contained works thus compiled with the Document, on account of their being thus compiled, if they are not themselves derivative works of the Document.

If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate.

13.8 Translation

Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail.

13.9 Termination

You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

13.10 Future Revisions of This License

The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See

Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.

ADDENDUM: How to use this License for your documents

To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:

Copyright © YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. A copy of the license is included in the section entitled ``GNU Free Documentation License''.

If you have no Invariant Sections, write ``with no Invariant Sections'' instead of saying which ones are invariant. If you have no Front-Cover Texts, write ``no Front-Cover Texts'' instead of ``Front-Cover Texts being LIST''; likewise for Back-Cover Texts.

If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.

About this document ...

Aspell Devel Docs

This document was generated using the LaTeX2HTML translator Version 2002 (1.62)

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

The command line arguments were:
latex2html -split 3 -toc_depth 3 -dir dev-html -long_titles 2 -local_icons -show_section_numbers devel.tex

The translation was initiated by Kevin Atkinson on 2004-01-30

next_inactive up previous
Kevin Atkinson 2004-01-30