AbiWord now simply loads the XLFD for the encoding and registry
fields, and trusts them. If the XLFD says "iso-8859-2", but the
font is encoded for iso-8859-1, then it's just a bug in the
fonts.dir and should be fixed there. Right now, those fields are
probably set to something completely incorrect ("abiword"?), just
because I knew we'd have to put something meaningful there, but
didn't know what that was a few months ago.
It works the same way for adding fonts; if the XLFD correctly
matches the encoding in the font, the font should work
as expected (and be available only for those characters it
supports). If the field is wrong, you get funny things. :)
> The second one is more complicated. I don't use Linux, but there are
> enought Linux users around me, so I can ask them if I need something.
> However, all of them use Debian and RedHat is sort of a uncharted
> territory for me. Some time ago somebody told me that RedHat Linux
> has a package for Latin 2 fonts, but they are marked as
> adobe-fontspecific. IMO, this is a bug in the package and should be
> corrected at the source of the problem.
I'm not sure what Red Hat ships, but I should look into the Latin-2
fonts it offers. Offhand, I suspect these are simply display fonts
(PostScript Type1 PFA or PFB) and lack print metrics, which would
make them of little use to us right away. It may be possible to
freely redistribute these fonts and their metrics, though.
-- Shaw Terwilliger