Crazy Rebel: викификация, оформление, иллюстрация

Crazy Rebel — Mon, 06 Apr 2009 09:39:47 GMT

викификация, оформление, иллюстрация

Новая статья

: ''Aspell'' и ''Enchant'' Снабдите свои программы функцией проверки орфографии

==Очепятки не пройдут==

: Пытаясь набрать это предложение, наш редактор допустил три описки. И что бы он делал без модуля проверки орфографии? '''Петр Семилетов''' расскажет, как прикрутить такой к вашей программе.

{{Врезка|Содержание=[[Изображение:LXF100_90_1.jpg|300px]]|Ширина=300px}}

Потребность в движках проверки орфографии растет с развитием общения через Интернет. Если раньше ошибки правописания подсвечивались разве что в текстовых редакторах и процессорах, то нынче это делают и браузеры, и программы для
обмена мгновенными сообщениями. Сложно сказать, улучшает ли
компьютерная проверка орфографии грамотность человека. С одной
стороны, пользователь сразу видит свои ошибки и в следующий раз
может написать слово правильно. Однако, полагаясь в грамотности на
машину, не потакает ли человек лени своего разума?

На этом уроке мы не будем задаваться столь философскими вопросами, а просто рассмотрим, как задействовать движок проверки правописания ''Aspell'' в своих программах. Мы будем использовать API для языка ''С'', а для большей наглядности практического применения ряд
примеров будет дан с привязкой к ''GTK+'' (мы публиковали серию статей
о нем в период с [[LXF86:GTK+|LXF86 по LXF95]], так что вы найдете все эти уроки
на LXFDVD), однако, изложенные общие принципы работы применимы
к любой библиотеке. В конце материала будет уделено немного места
еще одному движку – ''Enchant'', для сравнения. Также обратите внимание на ''Hunspell'' – он уже используется в ''OpenOffice.org'', а со временем
должен заменить ''MySpell'' и в продуктах Mozilla.

===ЧАСТЬ 1: GNU ''Aspell''===

''Aspell'' (http://aspell.net) – один из самых популярных движков проверки
орфографии. Он состоит из консольной программы (которой, помимо
прочего, можно передавать данные через канал), а также библиотеки с
«сишным» API, хотя сам ''Aspell'' написан на ''С++''. Работы с каналами мы
касаться не будем.

Описанию API в документации ''Aspell'' уделено мало внимания –
несколько примеров да примечания. Чтобы использовать ''Aspell'' в своей
программе, надо изучить его исходные тексты – причем не только заголовочные файлы. Но сначала не будет излишним прочесть эту статью.

Начнем с проверки, установлена ли ''LibAspell'' в системе пользователя, и включения ее в параметры компилятора. По какой-то причине библиотека не оснащена модулем для ''pkg-config'', поэтому искать '''pc'''-файл
бесполезно. Вместо этого, в случае ''Autotools'', следует добавить в файл
'''configure.in''' (который будет обработан '''autogen.sh''' для создания скрипта
''configure'') макросы для проверки наличия заголовочного файла '''aspell.h''':

<source lang=c_mac>
AC_CHECK_HEADER(aspell.h,
LIBS=”$LIBS -laspell”
AC_DEFINE(HAVE_LIBASPELL, 1, [use aspell]),
[AC_MSG_ERROR([cannot find header for libaspell])]
)
</source>

Напомню формат макроса '''AC_CHECK_HEADERS''':

AC_CHECK_HEADERS (имя заголовочного файла, [действие в положительном случае], [действие в отрицательном])

Итак, мы проверяем, есть ли в системе файл '''aspell.h'''. Если есть, то
в файле '''config.h''' определяется флаг '''HAVE_LIBASPELL''', чтобы потом в
коде программы мы могли написать что-то вроде:

<source lang=c>
#ifdef HAVE_LIBASPELL
#include “aspell.h”
#endif
</source>

В приведенном выше примере, для вывода сообщения об ошибке был использован макрос '''AC_MSG_ERROR'''. Помимо прочего, он вызывает прекращение работы сценария '''configure'''. То есть, если '''aspell.h''' не была найден, то и настройка исходных текстов будет провалена. Если
такое поведение нежелательно, а наличие '''aspell.h''' – необязательное
условие для сборки вашей программы, то проверка может выглядеть
немного иначе:

<source lang=c_mac>
AC_CHECK_HEADER(aspell.h,
LIBS=”$LIBS -laspell”
AC_DEFINE(HAVE_LIBASPELL, 1, [use aspell]),
echo “aspell.h not found”
)
</source>

Здесь, вместо использования сурового макроса мы просто выводим сообщение, что '''aspell.h''' не найден.

Приступим к работе с библиотекой. Первым делом создадим экземпляр класса '''AspellConfig'''. Класс этот служит для управления всякими
настройками. Именно всякими, поскольку он не входит в инкапсуляцию
других классов ''Aspell'', но может быть применен для изменения настроек других классов. Создадим экземпляр:

<source lang=c>
AspellConfig *config = new_aspell_config ();
</source>

После окончания работы его надо будет удалить при помощи функции '''delete_aspell_config()'''. Значения полей в классе можно менять при
помощи функции '''aspell_config_replace()'''. Формат вызова таков:

aspell_config_replace (config, имя переменной-поля, новое значение);

Давайте для примера настроим класс под русскую локаль и кодировку UTF-8:

<source lang=c>
aspell_config_replace (config, “lang”, “ru”);
aspell_config_replace (config, “encoding”, “UTF-8”);
</source>

Замечу, что у пользователя может быть другая локаль, тогда ваше ‘'''ru'''’ будет бесполезным. Поэтому лучше определить локаль программно. Для этого нужно прочитать значение переменной окружения
‘'''LANG''';. В ''GTK+'' это делается вот так:

<source lang=c>
gchar *lang = g_getenv (“LANG”);
if (lang)
aspell_config_replace (config, “lang”, lang);
else
aspell_config_replace (config, “lang”, “C”);
aspell_config_replace (config, “encoding”, “UTF-8”);
</source>

Если, вдруг, переменная ‘'''LANG'''’ не установлена, то мы используем
значение ‘'''C'''’ (стандартная англоязычная локаль). Что до кодировки, то
указывая UTF-8, мы сообщаем движку ''Aspell'', какую кодировку будем
использовать для обмена данными с ним. Изнутри ''Aspell'' восьмибитный, но мы можем передавать ему текст в UTF-8 и получать его обратно тоже в UTF-8. Полученным текстом может быть, например, список предположительно правильных написаний для данного (переданного
в параметре функции проверки) слова. Конечно, никто не мешает вам
использовать другую кодировку, но в современных условиях UTF-8 –
лучшая, если ваша библиотека виджетов ее поддерживает.

Еще одна подробность – в указанной вами кодировке ''Aspell'' будет
сохранять новые слова в пользовательском словаре. ''Aspell'' создает
такие словари в отдельных файлах (по одному на каждый использованный языковый модуль – то есть на тот модуль, куда было виртуально добавлено слово). Файлы эти лежат в домашнем каталоге пользователя. Например, имя файла с пользовательским словарем для русского
языка – '''~/.aspell.ru.pws'''.

Обратите внимание, что после каждой смены в движке текущего языка надо снова задавать кодировку, иначе движок будет работать в
кодировке по умолчанию. Если явно не указать кодировку для русского, ею будет KOI8-R.

Чтобы обеспечить программу возможностью использовать любой
доступный модуль проверки орфографии, необходимо получить список установленных модулей. В приведенном ниже примере мы получаем такой список и выводим имена модулей в консоль:

<source lang=c>
const AspellDictInfo *entry;
AspellConfig *config = new_aspell_config ();
AspellDictInfoList *dlist = get_aspell_dict_info_list (config);
AspellDictInfoEnumeration *dels = aspell_dict_info_list_elements (dlist);
while ((entry = aspell_dict_info_enumeration_next (dels)) != 0)
if (entry)
printf (“%s\n”, entry->name);
delete_aspell_dict_info_enumeration (dels);
delete_aspell_config (config);
</source>

Итогом работы этого кода будет нечто вроде:

ru
en
en_CA

и так далее.

Полученные названия можно использовать в '''aspell_config_replace()''', чтобы установить локаль движка ''Aspell'':

aspell_config_replace (config, “lang”, локаль);

Теперь у нас есть все знания для того, чтобы настроить язык и
кодировку. Но этого мало. Надо создать на основе этих данных экземпляр класса, отвечающего за проверку орфографии. Для этого API предоставляет нам две функции, которые мы рассмотрим подробно:

<source lang=c>
struct AspellCanHaveError* new_aspell_speller (struct AspellConfig *config);
struct AspellSpeller* to_aspell_speller (struct AspellCanHaveError *obj);
</source>

Внутри первой функции происходят любопытные вещи. ''Aspell'',
как уже упоминалось выше, написан на ''С++'', и «сишной» структуре
'''AspellCanHaveError''' соответствует внутренний класс '''CanHaveError''', а '''AspellSpeller''' – класс '''Speller'''. Итак, функция '''new_aspell_speller()''' создает экземпляр класса '''Speller'''. В случае ошибки '''new_aspell_speller()'''
возвращает экземпляр '''CanHaveError'''. В противном же случае возвращается '''Speller''', которого нужно «вытащить» из '''CanHaveError''' функцией '''to_aspell_speller()'''. Я понимаю, что API можно было сделать более
логичным.

Вот пример. Сначала вызываем '''new_aspell_speller''':

<source lang=c>
AspellCanHaveError *possible_err = new_aspell_speller(spell_config);
</source>

На этом этапе мы не знаем, что вернулось в '''possible_err''' на самом деле – экземпляр '''AspellCanHaveError''' или '''AspellSpeller'''. Поэтому объявляем '''spell_checker''' и проверяем '''possible_err''' – то есть вернулась ли
ошибка. Если да, то печатаем сообщение об ошибке, а если нет, то
функцией '''to_aspell_speller''' приводим '''possible_err''' к типу '''AspellSpeller'''.

<source lang=c>
AspellSpeller *spell_checker;
if (aspell_error_number (possible_err) != 0)
printf (“%s\n”, aspell_error_message (possible_err));
else
spell_checker = to_aspell_speller (possible_err);
</source>

Пара слов об освобождении памяти. Память для '''AspellCanHaveError'''
освобождается с помощью функции '''delete_aspell_can_have_error()''',
а для '''AspellSpeller – delete_aspell_speller()'''. В приведенном выше
коде, будь он в рабочей программе, освобождать память следовало бы так. Если вернулся экземпляр '''AspellSpeller''', то память для
'''AspellCanHaveError''' уже не нужно освобождать, потому что на самом-то
деле в '''possible_err''' хранится не экземпляр '''AspellCanHaveError''', а экземпляр '''AspellSpeller''', и вызовы обеих функций уничтожения объекта приведут к ошибке сегментации во второй из них.

Лучший вариант работы с памятью таков. Если вернулся
'''AspellCanHaveError''' – выполняем для него '''delete_aspell_can_have_error()'''
и завершаем код проверки орфографии. Если вернулся '''AspellSpeller''',
то проверяем орфографию и очищаем память с помощью '''delete_aspell_speller()''', однако '''delete_aspell_can_have_error()''' для '''possible_err'''
уже НЕ вызываем.

====Тонкая красная линия====

Получив на руки работоспособный экземпляр '''AspellSpeller''', мы, наконец, можем проверить написание слова. Для этого служит функция
'''aspell_speller_check()''':

<source lang=c>
int aspell_speller_check (struct AspellSpeller *speller, const char *word, int word_size);
</source>

Она возвращает нулевое значение, если слова нет в словаре, '''1''' – если есть, и '''-1''' в случае возникновения ошибки (в движке). То есть в
рабочем коде, если нам нужно просто проверить, есть слово в словаре или нет, и нас не волнует возможная внутренняя ошибка, то можно
писать так:

<source lang=c>
if (! aspell_speller_check (параметры)) {
делаем что-то - например, подчеркиваем ошибочное слово
}
</source>

Рассмотрим параметры функции поподробнее. Со speller’ом все
понятно. Слово '''word''', передаваемое для проверки, должно быть в той
кодировке, которую вы задали для словарного модуля. '''word_size''' – размер (в байтах) этого слова, может быть '''-1''', если мы имеем дело со
строкой, завершающейся нулем (‘'''\0'''’). Обычно так оно и есть.

Попробуем ''Aspell'' в деле. Как проверить орфографию в стандартном виджете текстового редактора ''GTK+'' (да и в ''GtkSourceView'', [[LXF97:GtkSourceView|см. LXF97]])?

Как вы, наверное, знаете, изменение атрибутов участков текста в '''GtkTextView''' осуществляется с помощью объектов-тэгов. Тэг несет в себе
параметры шрифта, цвет и так далее. Тэги хранятся в таблице, которая
подключается к '''GtkTextBuffer''' (именно к буферу, а не к '''GtkTextView''').
Сначала надо создать таблицу, а затем поместить в нее тэг.

Давайте создадим пустую таблицу:

<source lang=c>
GtkTextTagTable *tags_table = gtk_text_tag_table_new ();
</source>

Затем создадим тэг, которым будем подсвечивать ошибочные слова:

<source lang=c>
GtkTextTag *tag_spell_err = gtk_text_tag_new (“spell_err”);
</source>

Обратите внимание – мы даем тэгу имя '''spell_err''', чтобы потом иметь
возможность обратиться к нему. Назначим тэгу следующие свойства:
цвет букв (переднего плана, '''foreground''') и подчеркивание ('''underline'''):

<source lang=c>
g_object_set (G_OBJECT (tag_spell_err), “foreground”, “red”, NULL);
g_object_set (G_OBJECT (tag_spell_err), “underline”, PANGO_UNDERLINE_NORMAL, NULL);
</source>

В данном примере мы использовали стиль '''PANGO_UNDERLINE_NORMAL''' – обычное подчеркивание прямой линией. Но в библиотеке
''Pango'', начиная с версии 1.4, появился стиль '''PANGO_UNDERLINE_ERROR''', созданный специально для подчеркивания ошибок (волнистая линия мелким зигзагом). Как написать код, проверяющий версию ''Pango'' и устанавливающий стиль подчеркивания в зависимости от нее?
А вот так:

<source lang=c>
#if defined(PANGO_VERSION_CHECK) && PANGO_VERSION_CHECK(1,4,0)
g_object_set (G_OBJECT (tag_spell_err), “underline”, PANGO_UNDERLINE_ERROR, NULL);
#else
g_object_set (G_OBJECT (tag_spell_err), “underline”, PANGO_ UNDERLINE_SINGLE, NULL);
#endif
</source>

Теперь тэг можно поместить в таблицу:

gtk_text_tag_table_add (tags_table, tag_spell_err);

Создадим отдельный текстовый буфер с указанной таблицей тэгов:

GtkTextBuffer *text_buffer = gtk_text_buffer_new (tags_table);

У '''GtkTextView''' уже есть буфер по умолчанию. Заменим его на новый
буфер с нашей таблицей тэгов:

gtk_text_view_set_buffer (text_view, text_buffer);

Альтернативный вариант вариант – не создавать свой буфер и таблицу, а получить указатель на уже существующий буфер с помощью
функции '''gtk_text_buffer_get_tag_table()''', и добавить тэг в полученную
таблицу. Решение зависит от вас и от архитектуры вашей программы.

Приведем код, отвечающий непосредственно за проверку содержимого текстового буфера на ошибки:

<source lang=c>
GtkTextIter iter;
GtkTextIter a;
GtkTextIter b;
gchar *p = NULL;
gchar *text;
gtk_text_buffer_get_iter_at_offset (text_buffer, &iter, 0);
if (gtk_text_iter_starts_word (&iter))
a = iter;
do
{
if (gtk_text_iter_starts_word (&iter))
{
b = iter;
if (gtk_text_iter_backward_char (&b))
a = iter;
if (gtk_text_iter_forward_word_end (&iter))
if (gtk_text_iter_ends_word (&iter))
{
text = gtk_text_iter_get_slice (&a, &iter);
if (text)
{
if (g_utf8_strlen (text, -1) > 1)
{
if (! aspell_speller_check (text_buffer, text, -1))
{
gtk_text_buffer_apply_tag (text_buffer, gtk_text_tag_
table_lookup(gtk_text_buffer_get_tag_table (text_buffer), “spell_err”), &a, &iter);
g_free (text);
continue;
}
}
g_free (text);
}
}
}
}
while (gtk_text_iter_forward_char (&iter));
}
</source>

Неплохо, правда? Вначале мы получаем итератор '''iter''', указывающий на начало буфера. Также у нас есть вспомогательные итераторы
'''a''' и '''b''', которых мы используем для более точного последовательного
перебора букв в буфере. Перебирая в цикле один символ за другим,
мы получаем слова. Текст каждого слова помещаем в переменную '''text''' и передаем эту переменную в функцию '''aspell_speller_check()'''. Если
слова нет в словаре, то применяем цветовой тэг к участку в буфере,
отмеченному итераторами, которые ограничивают текущее слово. Тэг
применяется с помощью функции '''gtk_text_buffer_apply_tag()'''. Этой
функции передаются следующие параметры: '''text_buffer''' – текстовый
буфер, указатель на тэг. Его мы извлекаем по имени из таблицы тэгов,
которая назначена данному буферу. Делается это так:

gtk_text_tag_table_lookup(gtk_text_buffer_get_tag_table (text_buffer), “spell_err”)

Оставшиеся два параметра – итераторы, задающие начало и конец
отмечаемого тэгом участка в буфере. Вот вам задача для самостоятельного решения: перед вызовом кода подчеркивания ошибок надо
убрать возможное прежнее подчеркивание, ведь есть вероятность, что
пользователь уже проверял орфографию, а затем исправил некоторые
слова. Поэтому, прежде чем заново подчеркивать ошибки, найдите в
буфере все тэги с именем “'''spell_err'''” и удалите их.

====Помощь зала====

Помимо того, что ''Aspell'' может сообщить вам о наличии или отсутствии
слова в словаре, он также дает список возможных вариантов верного
написания предложенного слова. В приведенном ниже коде предполагается, что ошибочное слово хранится в переменной '''error_word''':

<source lang=c>
AspellWordList *suggestions = aspell_speller_suggest (speller, error_word, -1);
if (! suggestions)
; //например, выходим по return
//иначе получаем список предположений:
AspellStringEnumeration *elements = aspell_word_list_elements
(suggestions);
const char *word;
//и перебирая их (elements) по одному, печатаем в консоль:
while (word = aspell_string_enumeration_next (elements))
printf (“%s \n”, word);
//удаляем объект:
delete_aspell_string_enumeration (elements);
</source>

Не буду вдаваться в подробности внутреннего устройства этих
функций – скажу лишь, что API можно было сократить наполовину.
Память, полученную от '''aspell_speller_suggest()''', освобождать не нужно – возвращается указатель на '''const'''. Объект доступен до следующего
вызова вышеупомянутой функции.

Вот мы и рассмотрели основные функции ''Aspell''. Напоследок расскажу еще об одной, которой программисты пользуются очень часто –
это добавление нового слова в словарь. Пример очевиден:

<source lang=c>
aspell_speller_add_to_personal (speller, word, strlen (word));
aspell_speller_save_all_word_lists (speller);
</source>

Размер слова указывается в байтах, поэтому годится обычная '''strlen''', даже если слово у вас хранится в UTF-8. И не забывайте вызывать '''aspell_speller_save_all_word_lists()''', иначе слово хотя и добавитсяв текущую сессию проверки орфографии, но не будет сохранено в
словарном файле.

===ЧАСТЬ 2: ''Enchant''===

''Enchant'' – побочный продукт разработчиков ''AbiWord'' (http://www.abisource.com/enchant). Собственно говоря, это и не движок сам по себе, а
программная прослойка, предоставляющая доступ к другим движкам
проверки орфграфии, как-то: ''Aspell, ISpell, MySpell, Uspell, Hspell, AppleSpell'' и ''Hunspell''. Разработчики позаботились об удобном подключении библиотеки при компиляции – то бишь предоставили пакет
для ''pkg-config''. Поэтому, чтобы проверить наличие библиотеки и подключить ее к своей программе, надо добавить в '''configure.in''' примерно
следующее:

<source lang=bash>
echo -n “checking for enchant... “
if pkg-config --exists enchant ; then
LIBS=”$LIBS `pkg-config --libs enchant `”
CFLAGS=”$CFLAGS `pkg-config --cflags enchant `”
AC_DEFINE(ENCHANT_SUPPORTED, 1, [ENCHANT_
SUPPORTED])
echo “yes”
else
echo “no”
fi
Ну, а в коде программы:
#ifdef ENCHANT_SUPPORTED
#include “enchant.h”
#endif
</source>

Общение с ''Enchant'' происходит в кодировке UTF-8, вам не нужно указывать это напрямую. Инициализация словаря выполняется
просто:

<source lang=c>
EnchantBroker *broker = enchant_broker_init ();
EnchantDict *dict = NULL;
gchar *lang = g_getenv (“LANG”);
if (lang)
dict = enchant_broker_request_dict (broker, lang);
</source>

Вначале создается брокер, у которого запрашиваем словарь: брокер ими заведует. В приведенном выше примере мы просим у брокера:
«Дай нам словарь для языка текущей локали». Но ведь известно, что
''Enchant'' поддерживает одновременно несколько движков проверки
орфографии. Стало быть, ''Enchant'' даст нам (прозрачно, разумеется)
тот движок, в котором установлен модуль проверки нужного нам языка. Но что если такой модуль есть для нескольких движков? Например,
для ''Aspell'' и ''MySpell''? Для этих целей существует файл '''/usr/share/Enchant/Enchant.ordering''', в котором задаются приоритеты движков.
Расположение этого файла у вас может быть иным – всё зависит от
того, где установлен ''Enchant''. Может также существовать аналогичный
пользовательский файл, хранящийся в '''~/.enchant'''.

Далее, где именно ''Enchant'' ищет словари? Смотря какие. Для
''MySpell, Ispell'', и ''Uspell'' по умолчанию – в подкаталогах '''/usr/share/enchant''' (опять же, у вас может быть иначе). Например, словарь ''MySpell'' ищется в '''/usr/share/enchant/myspell'''. Что до ''Aspell'', то к нему ''Enchant''
ищет «общие» словари, без всякой привязки к конкретной установке.

Для проверки слова на правильность написания надо использовать
следующую функцию:

<source lang=c>
int
enchant_dict_check (EnchantDict *dict, const char *const word, ssize_tlen)
</source>

Она возвращает '''0''', если слово присутствует в словаре, положительное значение – если слова там нет, и отрицательное в случае внутренней ошибки движка. Параметры функции: '''dict''' – экземпляр словаря,
'''word''' – передаваемое для проверки слово (в UTF8), '''len''' – длина этого
слова в байтах, можно использовать '''strlen''' либо значение '''-1''', если строка завершается нулем.

Получение списка предположительно верных написаний слова:

<source lang=c>
size_t out_n_suggs;
gchar **words = enchant_dict_suggest (dict, s, -1, &out_n_suggs);
</source>

Здесь слова-предположения помещаются в строковой массив
'''words'''. Количество элементов массива возвращается в переменной
'''out_n_suggs'''. А чтобы освободить память, отведенную под этот массив,
нужно сделать так:

enchant_dict_free_string_list (dict, words);

Наконец, после работы с брокером и словарем нужно тоже очищать память:

<source lang=c>
if (dict)
enchant_broker_free_dict (broker, dict);
if (broker)
enchant_broker_free (broker);
</source>

Легко видеть, что API у ''Enchant'' более простое, чем у ''Aspell''.
Использование того или иного движка зависит от программы. Мне
кажется, что наилучшее решение – это поддержка сразу нескольких
движков в зависимости от того, какие из них установлены. Собственно,
этим и занимается ''Enchant'', но ''Aspell'' более традиционен для Linux и
работает «из коробки» в большинстве дистрибутивов. Кроме того,
даже при наличии ''Enchant, Aspell'' с его 70 словарями наверняка будет
использоваться тем же ''Enchant'' в качестве движка. '''LXF'''

LXF100-101:Урок грамматики - История изменений

Crazy Rebel: /* Очепятки не пройдут */

Crazy Rebel: викификация, оформление, иллюстрация

← Предыдущая		Версия 11:00, 6 апреля 2009
Строка 18:		Строка 18:
	примеров будет дан с привязкой к ''GTK+'' (мы публиковали серию статей		примеров будет дан с привязкой к ''GTK+'' (мы публиковали серию статей
	о нем в период с [[LXF86:GTK+\|LXF86 по LXF95]], так что вы найдете все эти уроки		о нем в период с [[LXF86:GTK+\|LXF86 по LXF95]], так что вы найдете все эти уроки
-	~~на LXFDVD~~), однако, изложенные общие принципы работы применимы	+	по ссылке), однако, изложенные общие принципы работы применимы
	к любой библиотеке. В конце материала будет уделено немного места		к любой библиотеке. В конце материала будет уделено немного места
	еще одному движку – ''Enchant'', для сравнения. Также обратите внимание на ''Hunspell'' – он уже используется в ''OpenOffice.org'', а со временем		еще одному движку – ''Enchant'', для сравнения. Также обратите внимание на ''Hunspell'' – он уже используется в ''OpenOffice.org'', а со временем