Title: Enchant
URL: http://www.abisource.com
Date: Apr 20, 2024

Enchant

by Dom Lachowicz

Current maintainer: Reuben Thomas

Enchant is now hosted on Github

New website ! (hosted on GitHub pages too)

News

April 1, 2010: Enchant 1.6.0 released. See below for download information.

May 23, 2009: Enchant 1.5.0 released. See below for download information.

May 5, 2008: Enchant 1.4.2 released. See below for download information.

October, 2003: Enchant is listed in the Freedesktop.org software repository!

GnomeSpell and GtkSpell use Enchant!

LibSexy uses Enchant

KDE/KOffice folks considering using Enchant

What is Enchant?

On the surface, Enchant appears to be a generic spell checking library. You can request dictionaries from it, ask if a word is correctly spelled, get corrections for a misspelled word, etc...

Beneath the surface, Enchant is a whole lot more - and less - than that. You'll see that Enchant isn't really a spell checking library at all.

"What's that?" you ask. Well, Enchant doesn't try to do any of the work itself. It's lazy, and requires backends to do most of its dirty work. Looking closer, you'll see the Enchant is more-or-less a fancy wrapper around the dlopen() system call. Enchant steps in to provide uniformity and conformity on top of these libraries, and implement certain features that may be lacking in any individual provider library. Everything should "just work" for any and every definition of "just working."

Enchant, Pipes, API, and ABI

Enchant does not use pipes to talk with command line programs. Enchant is a full-fledged library, with a C and C++ API. Its communication with its various backends happens via "virtual function calls", or at least the C equivalent thereof. The backends are small C/C++ plugins. The backends themselves do not use the popen() call, but instead link to various libraries (eg: aspell) and interface with said library's API to "get the job done."

Further, enchant has a standard C API/ABI that will in due course be frozen for all of eternity, barring any gross oversights or shortcomings introduced by the author. I believe the current API to be rather sufficient for my various projects' needs. It may not, however, be sufficient for yours. If not, please read on to the "Enchant and Collaboration" section below.

No pipes? But I thought you support Ispell!

Enchant does support most Ispell dictionaries. Back in the day, I and some other folks from the AbiWord team forked Ispell in order to turn it into a C library. Unfortunately, it had a lot of Ispell "global state" cruft in it. Since then, we have turned this library into a stateful C++ library, complete with 1st-class classes and objects. In the process, we also believe that we've made Ispell more flexible, and that there is room for further flexibility still. Enchant's Ispell backend is based on this work done by myself and others inside of AbiWord.

Command Lines

Enchant is not another "ispell compatible" command line program. However, it does currently ship with one, as a "technology demo." The program currently isn't particularly good, especially when compared to 'aspell'. Contributions improving the command line program are generously welcomed.

Enchant and Wheels

As far as I know, Enchant re-invents no wheels here. This wheel is entirely new. Enchant doesn't implement its own correction code. It doesn't "duplicate" functionality already found in other projects, as frankly, it doesn't have much functionality of its own. Enchant wraps a common set of functionality present in a variety of existing products/libraries, and exposes a stable API/ABI for doing so. Where a library doesn't implement some specific functionality, Enchant will emulate it.

Backends

Enchant is capable of having multiple backends loaded at once. Currently, Enchant has 8 backends:

More/other backends are welcomed.

Enchant and multiple backends

Why would Enchant want to support multiple backends? There are several reasons for this.

Enchant and API Inspiration

Enchant's API was inspired by the Aspell/Pspell API, and aims to be both a superset and a "ease of code" simplification of said API.

All inputs and outputs are in UTF-8 encoding. All language tags are based on ISO standards, and take the form of "xx_YY" (language_LOCALE), where the locale ("_YY") portion is optional, but encouraged. We may consider extending the language tag mechanism to accomodate future needs, such as medical dictionaries.

Enchant and Multi-User systems

Enchant strives to support multi-user systems as well as is humanly possible. This in part means that users can have locally defined plugin backends for enchant (for example, in ~/.enchant/) that work with the spell checker of their choice. This is in addition to any globally installed plugin providers. The user-defined plugins are guaranteed to always take precedence.

Similarly, several of Enchant's backends support user + global dictionaries. This includes the Ispell, Uspell, and Myspell backends. Users may have locally installed dictionaries (for example, in ~/.enchant/ispell or ~/.enchant/uspell) in addition to any globally installed ones. As with plugins, the user-defined dictionaries will always take precedence over the globally installed ones.

Also, both user-local and global Provider Ordering files can coexist, with the values in the user-local one guaranteed precedence. Further, an API exists so that one can modify said orderings at runtime, if necessary.

Why is this done?

Building Enchant

Enchant strives to be buildable with any toolchain, not just the GNU ones. Currently, the only ones that have been tested are the GNU one (or any toolchain capable of being driven by auto* and libtool) and MSVC. This, however, does not mean that we want to stop here. We want Enchant to build with the compiler and linker of your choice. For example, the fact that I don't own a copy of MSVC shouldn't stop you from sending me a DSW project file that is capable of building Enchant. I will add it gratefully.

Enchant is vanilla C and C++ code, and as such should be buildable with just about any C/C++ compiler known to man. Some of it is based on AbiWord code, which compiles on [Unix, MacOS, BeOS, QNX, Win32]. Some of it uses Glib2 code, which compiles on [Unix, MacOS, Win32, BeOS, QNX, ...]. In short, enchant's code should be highly portable. If something doesn't work for your $COMPILER on $PLATFORM, please send problem reports or patches that fix the problem. Other than that, the only "obstacle" should be getting a build system set up for Enchant for your particular $COMPILER and $PLATFORM, which shouldn't be too daunting of a task.

Enchant exposes 0 outside dependencies, save LibC. Internally, Enchant only requires Glib2 version 2.6 or later. This was done for pragmatic reasons - it's simply easier to use a portability library that handles modules, lists, etc... than writing one's own copy. That said, patches to remove the Glib2 dependency are welcomed. As I said, the decision to include it in the first place was extremely pragmatic. I didn't want to put it in, but I didn't want to rewrite a portability library, so I chose one I'm familiar with, is well tested, and works well. It saved me time getting the project off the ground. Now that it works and there is some outside interest, I'd wouldn't be saddened to see it go, provided that a viable alternative was implemented.

Getting Enchant

You can get Enchant from Github. https://github.com/AbiWord/enchant

Alternately, you can download Enchant 1.6.0 (April 1, 2010). Older versions are still available here.

You can browse the Enchant source online from: https://github.com/AbiWord/enchant. Enchant's public API can be found here. Enchant's provider plugin API can be found here. Enchant's C++ API can be found here.

Enchant and AbiWord [i.e. Collaboration]

Enchant was written by AbiWord's maintainer and lead developer. He also develops and maintains a lot of other software too. Enchant was inspired by a host of bugs in the AbiWord bugzilla. Please don't let the "AbiWord" part throw you for a loop.

The developer's intentions are for Enchant to be as widely adopted and successful as possible. He wants this to be used by (KOffice, OpenOffice, KDE, Gnome, ...). Patches and contributions from non-AbiWord developers are not only gladly welcomed, but strongly encouraged. Don't settle for mediocrity - stand up and be counted.

As with many proposed standards, the initial work on Enchant was done to address a real need in a real product by a real developer. It was not designed by committee. It addresses the author's needs remarkably well. Also like many standards, the author proposes his current body of work for discussion, collaboration, improvement, and ultimately standardization. It is often useful to have a working reference base in order to stimulate and direct discussion. The Enchant codebase is meant to do exactly that.

For the record, Enchant is already in use by AbiWord, while Lyx and Conglomerate are presently considering using it. Gnome-Spell and GtkSpell are currently in the works of transitioning between Pspell and Enchant. We hope to achieve broader use at an exponential level.

The current list for Enchant discussion is the AbiWord-devel list. Please see http://www.abisource.com/developers/ for more information on how to join, and for archives. If there is sufficient interest, I can look into moving this onto a separate, more "neutral" list, such as a Freedesktop.org one.

Issues with Enchant

Obviously, there are going to be issues, bugs, patches, RFEs, etc... for Enchant. These are gladly welcomed. You may do one of a few things (in my order of preference):

Enchant's Future

Some stuff that we're thinking about or are already in the process of adding:

Enchant's License

Enchant is currently licensed under the LGPL license, with an Exception so that non-free (as in speech and/or cost) plugin backends could be loaded and used by Enchant. This is mainly so that we can use the native spell checkers on various platforms (MacOS X, MS Office, ...), or that our users could "plug in" their favorite commercial product to do the job.

The author would consider re-licensing it as necessary to help foster broader adoption. This may include MPL or JCA/SISSL license, but the author would also consider alternate licenses as well.

What's in a Name?

"Enchant"'s English definition is roughly "to cast a spell" - whose meaning seemed to fit in well with a spelling-oriented framework. Add to that the fact that I wrote most of this this on a lonely Sunday morning while my gf was engrossed with "Harry Potter and the Order of the Phoenix", and you can see where I got its name ;-)

Copyright (C) 1998-2008, the AbiSource community. All rights reserved.
AbiSource, AbiSuite, and AbiWord are trademarks of Dom Lachowicz. All other product names, company names, or logos cited herein are property of their respective owners.
Site feedback to webmaster@abisource.com