[Fsf-friends] Language Info Needed for GNU Aspell
Frederick Noronha (FN)
fred@bytesforall.org
Wed Mar 24 12:12:11 IST 2004
[Please distribute this document as widely as possible.]
GNU Aspell 0.60 should be able to support most of the Word Languages.
This includes languages languages written in Arabic and other scripts
not well supported by an existing 8-bit character set. Eventually
Aspell should be able to support any current language not based on the
Chinese writing system.
GNU Aspell is a spell checker designed to eventually replace Ispell.
Its main feature is that it does a much better job of coming up with
possible suggestions than just about any other spell checker out there
for the English language, including Ispell and Microsoft Word.
However, starting with Aspell 0.60 is should also be the only Free (as
in Freedom) that can support most languages not written in the Latin or
Cyrillic scripts.
However I, the author of Aspell, know very little about foreign
languages (ie non-English) and what it takes to correctly spell check
them. Thus, I need other people to educate me.
If you speak a foreign language I would appreciate if you would take
the time too look over the following material and email me with any
additional information you may have.
The first part gives a thorough analysis of the languages which Aspell
can and cannot support. If you find any of this information is
incorrect please inform me at kevina@gnu.org.
When Aspell 0.60 is released I would like to have dictionaries
available for as many languages as possible.
Therefore, if you know of a Free word list available for a language that
is not currently listed as having a dictionary available I would
appreciate hearing form you. I am especially interested in working
with someone to add support for languages written in the Arabic
script. The encoding of the Arabic is quite complicated and I want to
be sure that Aspell can correctly handle it.
I would also appreciate some help converting Ispell dictionaries to
Aspell. So, if you would like to help convert some of the dictionaries
listed as being available for Ispell please contact me.
The second part lists languages related issues involved in correctly
spell checking a document. If you can offer any additional insight on
any of the issues discussed, or know of any additional complications
when spell checking a given language, I would appreciate hearing from
you.
The last part discusses why Aspell uses 8-bit characters internally
for your reading pleasure.
All of this material is also included in the Aspell 0.60 manual which
you can find at http://aspell.net/devel-doc/man.
Languages Which Aspell can Support
**********************************
Even though Aspell will remain 8-bit internally it should still be be
able to support any written languages not based on a logographic
script. The only logographic writing system in current use are those
based on hànzi which includes Chinese, Japanese, and sometimes Korean.
Supported
=========
Aspell 0.60 should be able to support the following languages as, to the
best of my knowledge, they all contain 220 or fewer symbols and can
thus, fit within an 8-bit character set. If an existing character set
does not exists than a new one can be invented. This is true even if the
script is not yet supported by Unicode as the private use area can be
used.
Code Language Name Script Dictionary Gettext
Available Translation
aa Afar Latin - -
ab Abkhazian Cyrillic - -
ae Avestan Avestan - -
af Afrikaans Latin Yes -
ak Akan Latin - -
an Aragonese Latin - -
ar Arabic Arabic - -
as Assamese Bengali - -
av Avar Cyrillic - -
ay Aymara Latin - -
az Azerbaijani Cyrillic - -
az Latin - -
ba Bashkir Cyrillic - -
be Belarusian Cyrillic Planned Yes
bg Bulgarian Cyrillic Yes -
bh Bihari Devanagari - -
bi Bislama Latin - -
bm Bambara Latin - -
bn Bengali Bengali Planned -
bo Tibetan Tibetan - -
br Breton Latin Yes -
bs Bosnian Latin - -
ca Catalan/Valencian Latin Yes -
ce Chechen Cyrillic - -
ch Chamorro Latin - -
co Corsican Latin - -
cr Cree Latin - -
cs Czech Latin Yes Yes
cu Old Slavonic Cyrillic - -
cv Chuvash Cyrillic - -
cy Welsh Latin Yes -
da Danish Latin Yes -
de German Latin Yes Yes
dv Divehi Thaana - -
dz Dzongkha Tibetan - -
ee Ewe Latin - -
el Greek Greek Yes -
en English Latin Yes Yes
eo Esperanto Latin Yes -
es Spanish Latin Yes Incomplete
et Estonian Latin Planned -
eu Basque Latin - -
fa Persian Arabic - -
ff Fulah Latin - -
fi Finnish Latin Planned -
fj Fijian Latin - -
fo Faroese Latin Yes -
fr French Latin Yes Yes
fy Frisian Latin - -
ga Irish Latin Yes Yes
gd Scottish Gaelic Latin Planned -
gl Gallegan Latin Yes -
gn Guarani Latin - -
gu Gujarati Gujarati - -
gv Manx Latin Planned -
ha Hausa Latin - -
he Hebrew Hebrew Planned -
hi Hindi Devanagari - -
ho Hiri Motu Latin - -
hr Croatian Latin Yes -
ht Haitian Creole Latin - -
hu Hungarian Latin Planned -
hy Armenian Armenian - -
hz Herero Latin - -
ia Interlingua (IALA) Latin Yes -
id Indonesian Latin Yes -
ie Interlingue Latin - -
ig Igbo Latin - -
ik Inupiaq Latin - -
io Ido Latin - -
is Icelandic Latin Yes -
it Italian Latin Yes -
iu Inuktitut Latin - -
jv Javanese Javanese - -
jv Latin - -
ka Georgian Georgian - -
kg Kongo Latin - -
ki Kikuyu/Gikuyu Latin - -
kj Kwanyama Latin - -
kk Kazakh Cyrillic - -
kl Kalaallisut/Greenlandic Latin - -
kn Kannada Kannada - -
ko Korean Hangeul - -
kr Kanuri Latin - -
ks Kashmiri Arabic - -
ks Devanagari - -
ku Kurdish Arabic - -
ku Cyrillic - -
ku Latin - -
kv Komi Cyrillic - -
kw Cornish Latin - -
ky Kirghiz Cyrillic - -
ky Latin - -
la Latin Latin - -
lb Luxembourgish Latin Planned -
lg Ganda Latin - -
li Limburgan Latin - -
ln Lingala Latin - -
lo Lao Lao - -
lt Lithuanian Latin Planned -
lu Luba-Katanga Latin - -
lv Latvian Latin - -
mg Malagasy Latin - -
mh Marshallese Latin - -
mi Maori Latin Yes -
mk Makasar Lontara/Makasar - -
ml Malayalam Latin - -
ml Malayalam - -
mn Mongolian Cyrillic - -
mn Mongolian - -
mo Moldavian Cyrillic - -
mr Marathi Devanagari - -
ms Malay Latin Yes -
mt Maltese Latin Planned -
my Burmese Myanmar - -
na Nauruan Latin - -
nb Norwegian Bokmal Latin Yes -
nd North Ndebele Latin - -
ne Nepali Devanagari - -
ng Ndonga Latin - -
nl Dutch Latin Yes Yes
nn Norwegian Nynorsk Latin Yes -
nr South Ndebele Latin - -
nv Navajo Latin - -
ny Nyanja Latin - -
oc Occitan/Provencal Latin - -
or Oriya Oriya - -
os Ossetic Cyrillic - -
pa Punjabi Gurmukhi - -
pi Pali Devanagari - -
pi Sinhala - -
pl Polish Latin Yes -
ps Pushto Arabic - -
pt Portuguese Latin Yes Yes
qu Quechua Latin - -
rm Raeto-Romance Latin - -
rn Rundi Latin - -
ro Romanian Latin Yes Yes
ru Russian Cyrillic Yes Yes
rw Kinyarwanda Latin - -
sa Sanskrit Devanagari - -
sc Sardinian Latin - -
sd Sindhi Arabic - -
se Northern Sami Latin - -
sg Sango Latin - -
si Sinhalese Sinhala - -
sk Slovak Latin Yes -
sl Slovenian Latin Yes -
sm Samoan Latin - -
sn Shona Latin - -
so Somali Latin - -
sq Albanian Latin Planned -
sr Serbian Cyrillic - Yes
sr Latin - -
ss Swati Latin - -
st Southern Sotho Latin - -
su Sundanese Latin - -
sv Swedish Latin Yes -
sw Swahili Latin Planned -
ta Tamil Tamil Planned -
te Telugu Telugu - -
tg Tajik Latin - -
tk Turkmen Latin - -
tl Tagalog Latin - -
tl Tagalog - -
tn Tswana Latin - -
to Tonga Latin - -
tr Turkish Latin - -
ts Tsonga Latin - -
tt Tatar Cyrillic - -
tw Twi Latin - -
ty Tahitian Latin - -
ug Uighur Arabic - -
ug Cyrillic - -
ug Latin - -
uk Ukrainian Cyrillic Yes -
ur Urdu Arabic - -
uz Uzbek Cyrillic - -
uz Latin - -
ve Venda Latin - -
vi Vietnamese Latin - -
vo Volapuk Latin - -
wa Walloon Latin Planned Incomplete
wo Wolof Latin - -
xh Xhosa Latin - -
yi Yiddish Hebrew - -
yo Yoruba Latin - -
za Zhuang Latin - -
zu Zulu Latin Planned -
Notes on Latin Languages
------------------------
Any word that can be written using on of the Latin ISO-8859 character
sets (ISO-8859-1,2,3,4,9,10,13,14,15,16) can be written, in decomposed
form, using the ASCII characters, the 23 additional letters:
U+00C6 LATIN CAPITAL LETTER AE
U+00D0 LATIN CAPITAL LETTER ETH
U+00D8 LATIN CAPITAL LETTER O WITH STROKE
U+00DE LATIN CAPITAL LETTER THORN
U+00DE LATIN SMALL LETTER THORN
U+00DF LATIN SMALL LETTER SHARP S
U+00E6 LATIN SMALL LETTER AE
U+00F0 LATIN SMALL LETTER ETH
U+00F8 LATIN SMALL LETTER O WITH STROKE
U+0110 LATIN CAPITAL LETTER D WITH STROKE
U+0111 LATIN SMALL LETTER D WITH STROKE
U+0126 LATIN CAPITAL LETTER H WITH STROKE
U+0127 LATIN SMALL LETTER H WITH STROKE
U+0131 LATIN SMALL LETTER DOTLESS I
U+0138 LATIN SMALL LETTER KRA
U+0141 LATIN CAPITAL LETTER L WITH STROKE
U+0142 LATIN SMALL LETTER L WITH STROKE
U+014A LATIN CAPITAL LETTER ENG
U+014B LATIN SMALL LETTER ENG
U+0152 LATIN CAPITAL LIGATURE OE
U+0153 LATIN SMALL LIGATURE OE
U+0166 LATIN CAPITAL LETTER T WITH STROKE
U+0167 LATIN SMALL LETTER T WITH STROKE
and the 14 modifiers:
U+0300 COMBINING GRAVE ACCENT
U+0301 COMBINING ACUTE ACCENT
U+0302 COMBINING CIRCUMFLEX ACCENT
U+0303 COMBINING TILDE
U+0304 COMBINING MACRON
U+0306 COMBINING BREVE
U+0307 COMBINING DOT ABOVE
U+0308 COMBINING DIAERESIS
U+030A COMBINING RING ABOVE
U+030B COMBINING DOUBLE ACUTE ACCENT
U+030C COMBINING CARON
U+0326 COMBINING COMMA BELOW
U+0327 COMBINING CEDILLA
U+0328 COMBINING OGONEK
Which is a total of 37 additional Unicode code points.
All ISO-8859 character leaves the characters 0x00 - 0x19 and 0x80 -
0x99 unmapped as they are generally used as control characters. Of
those, 0x02 - 0x19 and 0x80 - 0x99 may be mapped to anything in Aspell.
This is a total of 62 characters which can be remapped in any ISO-8859
character set. Thus, by remapping 37 of the 62 characters to the
previously specifed Unicode code-points, any modified ISO-8859 character
set can be used for any Latin languages covered by ISO-8859. Of course
decomposing every single accented character wastes a lot of space, so
only characters that can be not be represented in the precomposed form
should be broken up. By using this trick it is possible to store
foreign words in the correctly accented form in the dictionary even if
the precomposed character is not in the current character set.
Any letter in the Unicode range U+0000 - U+0249, U+1E00..U+1EFF
(Basic Latin, Latin-1 Supplement, Latin Extended-A, Latin Extended-B,
and Latin Extended Additional) can be represented using around 175
basic letters, and 25 modifiers which is less than 220 and can thus fit
in an Aspell 8-bit character set. Since this unicode range covers any
possible Latin language this special character set can be used to
reperesnt any word written using the Latin script if so desired.
Hangeul
-------
Koren in generally written in hangeul or a mixture of hanja and hangeul.
Aspell should be able to spell check the hangeul part of the writing.
In Hangeul letters individual letters, known as jamo, are grouped
together in syllable blocks. Unicode provided code points for both jamo
and the combined syllable block. The syllable blocks will need to be
decomposed into jamo in order for Aspell to spell check it.
Syllabic
========
Syllabic languages use a separate symbol for each syllable of the
language. Since most of them have more than 240 distinct characters
Aspell can not support them as is. However, all hope is not lost as
Aspell will most likely be able to support them in the future.
Code Language Name Script
am Amharic Ethiopic
cr Cree Canadian Syllabics
ii Sichuan Yi Yi
iu Inuktitut Canadian Syllabics
oj Ojibwa Ojibwe
om Oromo Ethiopic
ti Tigrinya Ethiopic
The Ethiopic Syllabary
----------------------
Even though the Ethiopic script has more than 220 distinct characters
with a little work Aspell can still handle it. The idea is to split
each character into two parts based on the matrix representation. The
first 3 bits will be the first part and could be mapped to `10000???'.
The next 6 bits will be the second part and could be mapped to
`11??????'. The combined character will then be mapped with the upper
bits coming first. Thus each Ethiopic syllabary will have the form
`11?????? 10000???'. By mapping the first and second parts to separate
8-bit characters it is easy to tell which part represents the consonant
and which part represents the vowel of the syllabary. This encoding of
the syllabary is far more useful to Aspell than if they were stored in
UTF-8 or UTF-16. In fact, the exiting suggestion strategy of Aspell
will work well with this encoding with out any additional
modifications. However, additional improvements may be possible by
taking advantage of the consonant-vowel structure of this encoding.
In fact, the split consonant-vowel representation may prove to be so
useful that it may be beneficial to encode other syllabary in this
fashion, even if they are less than 220 of them.
The code to break up a syllabary into the consonant-vowel parts does
not exists as of Aspell 0.60. However, it will be fairly easy to add
it as part of the Unicode normalization process once that is written.
The Yi Syllabary
----------------
A very large syllabary with 819 distince symbols. However, like
Ethiopic, it should be possible to support this script by breaking it
up.
The Unified Canadian Aboriginal Syllabics
-----------------------------------------
Another very large syllabary.
The Ojibwe Syllabary
--------------------
With only 120 distinct symbols, Aspell can actually support this one as
is. However, as previously mentioned, it may be beneficial to break it
up into the consonant-vowel representation anyway.
Unsupported
===========
These languages, when written in the given script, are currently
unsupported by Aspell for one reason or another.
Code Language Name Script
ja Japanese Japanese
km Khmer Khmer
ko Korean Hanja + Hangeul
pi Pali Thai
th Thai Thai
zh Chinese Hanja
The Thai and Khmer Scripts
--------------------------
The Thai and Khmer scripts presents a different problem for Aspell. The
problem is not that there are more than 220 unique symbols, but that
there are no spaces between words. This means that there is no easy way
to split a sentence into individual words. However, it is still
possible to spell check these scripts, it is just a lot more difficult.
I will be happy to work within someone who is interested in adding Thai
or Khmer support to Aspell, but it is not likely something I will do in
the foreseeable future.
Languages which use Hànzi Characters
------------------------------------
Hànzi Characters are used to write Chinese, Japanese, Korean, and were
once used to write Vietnamese. Each hànzi character represents a
syllable of a spoken word and also has a meaning. Since there are
around 3,000 of them in common usage it is unlikely that Aspell will
ever be able to support spell checking languages written using hànzi.
However, I am not even sure if these languages need spell checking since
hànzi characters are generally not entered in directly. Furthermore
even if Aspell could spell check hànzi the exiting suggestion strategy
will not work well at all, and thus a completely new strategy will need
to be developed.
Japanese
--------
Modern Japanese is written in a mixture of "hiragana", "katakana",
"kanji", and sometimes "romaji". "Hiragana" and "katakana" are both
syllabaries unique to Japan, "kanji" is a modified form of hànzi, and
"romaji" uses the Latin alphabet. With some work, Aspell should be
able to check the non-kanji part of Japanese text. However, based on
my limited understanding of Japanese hiragana is often used at the end
of kanji. Thus if Aspell was to simply separate out the hiragana from
kanji it would end up with a lot of word endings which are not proper
words and will thus be flagged as misspellings. However, this can be
fairly easily rectified as text is tokenized into words before it is
converted into Aspell's internal encoding. In fact, some Japanese text
is written in entirely in one script. For example books for children
and foreigners are sometimes written entirely in hiragana. Thus,
Aspell could prove at least somewhat useful for spell checking Japanese.
Languages Written in Multiple Scripts
=====================================
Aspell should be able to check text written in the same language, but in
multiple scripts, with some work. If the number of unique symbols in
both scripts is less than 220 than a special character set can be used
to allow both scripts to be encoding in the same dictionary. However
this may not be the most efficient solution. An alternate solution is
to store each script in its own dictionary and allow Aspell to chose
the correct dictionary based on which script the given word is written
in. Aspell currently does not support this mode of spell checking
however it is something that I hope to eventually support.
Notes on Planned Dictionaries
=============================
be Belarusian Ispell Dictionary available
bn Bengali Unoffical Aspell Dictionary available
`http://www.bengalinux.org/downloads/'
et Estonian Ispell Dictionary available
fi Finnish Ispell Dictionary available
gd Scottish Ispell Dictionary available.
Gaelic `http://packages.debian.org/unstable/text/igaelic'
gv Manx Ispell Dictionary available.
`http://packages.debian.org/unstable/text/imanx'
he Hebrew Ispell Dictionary available
hu Hungarian MySpell dictionary expanded to over 500 MB. Will add
once affix support is worked into the dictionary
package system.
lb Luxembourgish MySpell dictionary planned.
lt Lithuanian MySpell dictionary expanded to over 500 MB. Will add
once affix support is worked into the dictionary
package system.
mt Maltese Unofficial Aspell Dictionary available, but broken
link to source.
`http://linux.org.mt/article/spellcheck'
sw Albanian Ispell Dictionary available
sw Swahili Available at
`http://sourceforge.net/projects/translate'. Offical
version comming soon.
ta Tamil Word list available at
`http://www.developer.thamizha.com/spellchecker/index.html'.
Working with them to create an Aspell dictionary.
wa Walloon Ispell Dictionary available
zu Zulu Available at
`http://sourceforge.net/projects/translate'. Offical
version comming soon.
References
==========
The information in this chapter was gathered from numerous sources,
including:
* ISO 639-2 Registration Authority,
`http://www.loc.gov/standards/iso639-2/'
* Languages and Scripts (Offical Unicode Site),
`http://www.unicode.org/onlinedat/languages-scripts.html'
* Omniglot - a guide to written language, `http://www.omniglot.com/'
* Winkipedia - The Free Encyclopedia, `http://wikipedia.org/'
* Ethnologue - Languages of the World, `http://www.ethnologue.com/'
* World Languages - The Ultimate Language Store,
`http://www.worldlanguage.com/'
* South African Languages Web, `http://www.languages.web.za/'
* The Languages and Writing Systems of Africa (Global Advisor
Newsletter), `http://www.intersolinc.com/newsletters/africa.htm'
Special thanks goes to Era Eriksson for helping me the information in
this chapter.
Language Related Issues
***********************
Here are some language related issues that a good spell checker needs to
handle. If you have any more information about any of these issues, or
of a new issue not discussed here, please email me at <kevina@gnu.org>.
German Sharp S
==============
The German Sharp S or Eszett does not have an uppercase equivalent.
Instead when `ß' is converted to `SS'. The conversion of `ß' to `SS'
requires a special rule, and increases the length of a word, thus
disallowing inplace case conversion. Furthermore, my general rule of
converting all words to lowercase before looking them up in the
dictionary won't work because the conversion of `SS' to lowercase is
ambiguous; it can be `ss' or `ß'. I do plan on dealing with this
eventually, however.
Compound Words
==============
In some languages, such as German, it is acceptable to string two words
together, thus forming a compound word. However, there are rules to
when this can be done. Furthermore, it is not always sufficient to
simply concatenate the two words. For example, sometimes a letter is
inserted between the two words. I tried implementing support for
compound words in Aspell but it was too limiting and no one used it.
Before I try implementing it again I want to know all the issues
involved.
Context Sensitive Spelling
==========================
In some language, such as Luxembourgish, the spelling of a word depends
on which words surround it. For example the the letter `n' at the end
of a word will disappear if it is followed by another word starting
with a certain letter such as an `s'. However, it can probably get
more complicated than that. I would like to know how complicated before
I attempt to implement support for context sensitive spelling.
Unicode Normalization
=====================
Because Unicode contains a large number of precomposed characters there
are multiple ways a character can be represented. For example letter
a* can either be represented as
U+00E5 LATIN SMALL LETTER A WITH RING ABOVE
or
U+0061 LATIN SMALL LETTER A + U+030A COMBINING RING ABOVE
By performing normalization first Aspell will only see one of these
representations. The exact form of normalization depends on the
language. Give the choice of
1. Precomposed character
2. Base letter + combining character(s)
3. Base letter only
if the precomposed charter is in the target character set then (1), if
both the base and combing character is present than (2), otherwise (3).
Words With Spaces or other Symbols in Them
==========================================
Many languages, including English, have words with non-letter symbols in
them. For example the apostrophe. These symbols generally appear in
the middle of a word, but they can also appear at the end, such as in an
abbreviation. If a symbol can _only_ appear as part of a word than
Aspell can treat it as if it were a letter.
However, the problem is most of these symbols have other uses. For
example, the apostrophe is often used as a single quote and the
abbreviations marker is also used as a period. Thus, Aspell can not
blindly treat them as if they were letters.
Aspell currently handles the case where the symbol can only appear in
the middle of the word fairly well. It simply assumes that if there is
a letter both before and after the symbol than it is part of the word.
This works most of the time but it is not fool proof. For example,
suppose the user forgot to leave a space after the period:
... and the dog went up the tree.Then the cat ...
Aspell would think "tree.Then" is one word. A better solution might be
to then try to check "tree" and "Then" separately. But what if one of
them is not in the dictionary? Should Aspell assume "tree.Then" is one
word?
The case where the symbol can appear at the beginning or end of the
word is more difficult to deal with. The symbol may or may not
actually be part of the word. Aspell currently handles this case by
first trying to spell check the word with the symbol and if that fails,
try it without. The problem is, if the word is misspelled, should
Aspell assume the symbol belongs with the word or not? Currently
Aspell assumes it does, which is not always the correct thing to do.
Numbers in words present a different challenge to Aspell. If Aspell
treats numbers as letters than every possible number a user might write
in a document must be specified in the dictionary. This could be
easily be solved by having special code to assume all numbers are
correctly spelled. But what about something like "4th". Since the
"th" suffix can appear after any number we are left with the same
problem. The solution would be to have a special symbol for "any
number".
Words with spaces in them, such as foreign phrases, are even more
trouble to deal with. The basic problem is that when tokonizing a
string there is no good way to keep phrases together. One solution is to
use trial and error. If a word is not in the dictionary try grouping it
with the previous or next word and see if the combined word is the
dictionary. But what if the combined word is not, should the misspelled
word be grouped when looking for suggestions? One solution is to also
store each part of the phrase in the dictionary, but tag it as part of a
phrase and not an independent word.
To further complicate things, most applications that use spell
checkers are accustom to parsing the document themselves and sending it
to the spell checker a word at a time. In order to support word with
spaces in them a more complicated interface will be required.
Notes on 8-bit Characters
*************************
There is a very good reason I use 8-bit characters in Aspell. Speed and
simplicity. While many parts of my code can fairly be easily be
converted to some sort of wide character as my code is clean. Other
parts can not be.
One of the reasons because is many, many places I use a direct lookup
to find out various information about characters. With 8-bit characters
this is very feasible because there is only 256 of them. With 16-bit
wide characters this will waste a LOT of space. With 32-bit characters
this is just plain impossible. Converting the lookup tables to some
other form, while certainly possible, will degrade performance
significantly.
Furthermore, some of my algorithms relay on words consisting only on
a small number of distinct characters (often around 30 when case and
accents are not considered). When the possible character can consist of
any Unicode character this number because several thousand, if that. In
order for these algorithms to still be used some sort of limit will
need to be placed on the possible characters the word can contain. If I
impose that limit, I might as well use some sort of 8-bit characters
set which will automatically place the limit on what the characters can
be.
There is also the issue of how I should store the word lists in
memory? As a string of 32 bit wide characters. Now that is using up 4
times more memory than charters would and for languages that can fit
within an 8-bit character that is, in my view, a gross waste of memory.
So maybe I should store them is some variable width format such as
UTF-8. Unfortunately, way, way to many of may algorithms will simply
not work with variable width characters without significant
modification which will very likely degrade performance. So the
solution is to work with the characters as 32-bit wide characters and
than convert it to a shorter representation when storing them in the
lookup tables. Now than can lead to an inefficiency. I could also use
16 bit wide characters however that may not be good enough to hold all
of future versions of Unicode and it has the same problems.
As a response to the space waste used by storing word lists in some
sort of wide format some one asked:
Since hard drive are cheaper and cheaper, you could store
dictionary in a usable (uncompressed) form and use it directly
with memory mapping. Then the efficiency would directly depend on
the disk caching method, and only the used part of the
dictionaries would relay be loaded into memory. You would no more
have to load plain dictionaries into main memory, you'll just want
to compute some indexes (or something like that) after mapping.
However, the fact of the matter is that most of the dictionary will
be read into memory anyway if it is available. If it is not available
than there would be a good deal of disk swaps. Making characters 32-bit
wide will increase the change that there are more disk swap. So the
bottom line is that it will be cheaper to convert the characters from
something like UTF-8 into some sort of wide character. I could also use
some sort of disk space lookup table such as the Berkeley Database.
However this will *definitely* degrade performance.
The bottom line is that keeping Aspell 8-bit internally is a very
well though out decision that is not likely to change any time soon.
Fell free to challenge me on it, but, don't expect me to change my mind
unless you can bring up some point that I have not thought of before
and quite possible a patch to solve cleanly convert Aspell to Unicode
internally with out a serious performance lost OR serious memory usage
increase.
--
http://kevin.atkinson.dhs.org
_______________________________________________
GNU Announcement mailing list <info-gnu@gnu.org>
http://mail.gnu.org/mailman/listinfo/info-gnu
More information about the Fsf-friends
mailing list