Subject: Re: RemapGlyph()
From: Tomas Frydrych (tomas@frydrych.uklinux.net)
Date: Tue Jun 26 2001 - 05:18:28 CDT
Hi Andrew,
another longish email ...
> > You can use 16 bit fonts with AW, but only under utf-8 locale; this
> > is logical, to declare your locale encoding as ISO-8859-1 is the
> > same as to say that you do not care about characters outside of
> > iso 8859-1.
> Is this locale dependence due to Unix, X, or AbiWord?
In principle this is an AW issue; when I have first came across
AW, it was capable of using only 8-bit char sets (except the CJK,
which I do not entirely understand how it works :-)). For my needs
this was not enough, I need to be able to combine the latin char
set with Greek, Hebrew and Syriac, and that requires Unicode. So I
added the support for 16-bit fonts. However, there are some
complications. The only 16-bit fonts available and suitable for AW
are ttf; you can download them from MS for free, but cannot
distribute them, and further, it still cannot be assumed that X
supports ttf fonts, since this is only true as of XFree 4, and many
AW users run XFree 3. Thus, the 16 bit fonts have to be setup by
the user as an option, rather than by the AW installer.
There are other issues; for instance the 16-bit font has to be
registered with X as using iso10646-1 encoding and addressed
directly through Unicode while a latin1 font will be registered as
iso8859-1 and accessed by the appropriate 8-bit values; if your
locale is setup to use say iso8859-1, AW has to normally do
Unicode -> Latin1 conversion before accessing a font, which
means it will only be able to access the first 256 chars in your 16-
bit font. To get around this AW has to determine that the font is 16-
bit and skip the conversion. Gtk does not make this possible, it
requires a direct call to the X API. Also, generating the PS output
to print from the 16-bit locale is more complex, because the PS file
is pure 8-bit, and all glyphs above 256 have to be referenced by
name -- you need a look up table that allows you to translate the
Unicode values into the glyph names; such a LUT is font specific,
due to lack of adherence to the PS standard glyph names.
Further, the X handling of ttf fonts is unefficient, requiring a lot of
resources (I suspect X duplicates much of the information that the
ttf rendering engine already stores in memory).
Overall, the 16-bit font usage requires quite a bit of extra
processing by the drawing engine; since drawing performance is
one of the weaker points of AW, it seemed best to me to make the
Unicode locale (utf-8) a special case, leaving the processing for the
standard 8-bit locales pretty much as it was. In principle, it would
be possible to enable the 16-bit fonts for all locales, but the user
would still have to setup any 16-bit fonts on their own, in which
case they can just as well change the locale encoding to utf-8
before running AW.
> I'm a Windows hater through and through but I'm sure glad they
> don't make the locale's encoding the "bible". It's just a
> recommendation for 8-bit charset apps.
The real difference between Windows and X is that the Windows
font rendering is Unicode based, that is, all ttf fonts for use with
Windows are Unicode coded, and so any Unicode based
application has access to all glyphs such a font contains (and any
non-Unicode application does implicit locale -> Unicode conversion
through the use of the A type API). In contrast, the coding of fonts
under X is arbitrary, and is largely 8-bit. This means that even
thought you do not have to adhere to your locale, things get hard
when you do not, particularly when you insist on using a char sets
greater than 256.
> full control. Unix should always be about full control. Mac and
> Windows should be for dummies. Mac has had WorldScript since eons
> ago and Windows has had Unicode since NT. Why does Unix come out
> as the stunted OS? (:
You may want to have a look at Markus Kuhn's Unicode pages
(you will have to search for them, do not have the address handy).
> So does Abi ship with these 16-bit fonts? Are there some free ones
> I can get? Do I have to run a UTF-8 locale? Does it require
> arcane massaging of files? I just wish my Linux setup wasn't
> such rubbish right now and I'd go teach myself all this.
No it does not ship 16-bit fonts, for reasons already stated, but you
can use your standard windows fonts with AW, and yes, you need
to at least pretend to use utf-8 locale (all you should need to do is
to set LANG to something like en_GB.UTF-8 before running AW);
you will find instructions on how to set up the ttf fonts in
UnixFonts.txt and UnixLocale.txt at the top of the source tree.
> Fortunately, I've learned that Unicode does in fact support
> Vietnamese without combining characters. The down-side is that all
> the legacy encodings are 8 bit combining character encodings and
> iconv (rightly) converts them to Unicode with the combining
> characters left in. I think the plain text import/export will end
> up with an "expert mode" sooner or later.
The bidi build has support for combining characters, as I needed
this for Hebrew; it uses a lookup table which lists overstriking
characters (see ut_OverstrikingChars.h/cpp). Perhaps this should
be moved out of the bidi build into the regular build, or you will need
to use the bidi build for Vietnamese.
(BTW, RemapGlyph() function returns 0 for the overstriking
characters not because they are overstriking, but because they are
not in your font; under X overstriking characters will get treated as if
they are normal chars with positive widths).
Tomas
*********************************************
tomas@frydrych.net / www.frydrych.net
PGP keys: http://www.frydrych.net/contact.html
This archive was generated by hypermail 2b25 : Tue Jun 26 2001 - 05:22:23 CDT