Thanks. From my point of view, this will put AbiWord in fron of StarWriter.
People were requesting that for a year or two, but it looks like
they don't have intention of implementing it. I'm sorry I can't help,
because I don't know a thing about C++.
> My uncertainty is about mapping those user-friendly names
> to actual encodings. Will there always be a 1:1 mapping
> of, say, "Latin 1" to "iso-8859-1"? Will "Greek" always
> fall into, say "iso-8859-5", or will there be different
> flavors of local languages spread across different
> ISO encodings?
Depends. While you are working with Type 1 fonts only, everything should
work as expected. Some people use non-standard encodings, but that
is mostly because they took, say iso-8859-1 font, changed a few
characters they need for a particular language and then they are
calling it iso-8859-2. My font in xterm is exactly like that, since Sun
didn't provide enough Lucida Sans Typewriter fonts for Latin 2.
That works because I really need only 10 characters from Latin 2.
If I needed more, I'd have to use a real Latin 2 font. I would
never expect from an application to guess that I don't have a full
Latin 2 font.
And there are non-ISO encodings which people use. KOI8-R is sort of
a standard for Russian, regardless of iso-8859-5, but you really
want input from a native speaker about this. However, KOI8-R fonts
should look as "-*-koi8-r" as far as XLFD is concerned.
If you start messing with TrueType one day, there could be surprises.
I've seen TrueType fonts with messed up encodings, when they were
used through a Unix font server. There might be a problem if a user has
Abi fonts in the font path after the TrueType ones. I suppose that's why
you have AbiSource in font names. That way you can't end up with the
wrong one on the screen.
--
.-. .-. Life is a sexually transmitted disease.
(_ \ / _)
| dave@srce.hr
| dave@fly.cc.fer.hr