Re: Looking up fonts and shapers in Pango
- From: Steve Underwood <steveu coppice org>
- To: gtk-i18n-list redhat com
- Subject: Re: Looking up fonts and shapers in Pango
- Date: Sun, 23 Jan 2000 21:42:03 +0800
Owen Taylor wrote:
> hashao <hashao@telebot.com> writes:
>
> > Hello Owen,
> >
> > Friday, January 21, 2000, 5:40:52 AM, you wrote:
> > ...
> > OT> - Choosing a font for each character.
> > OT> - Choosing a shape engine for each character (handles conversion of
> > OT> characters into font-specifc glyphs)
> >
> > ...
> > OT> The other approach that I've thought of for handling the font-coverage
> > OT> problem is to simply punt the procedure to the installation process.
> >
> > OT> That is, to assume that the person/vendor that is setting up system
> > OT> fonts, and also the person distributing 3rd party fonts have good
> > OT> knowledge of what shapers will be available. For instance, somebody
> > OT> installing an X font encoded as tscii-0 assumes that a Tamil shaper is
> > OT> available and then claims the coverage range for the font is
> > OT> U+0B80 - U+0B8F, and installs some appropriate line in a global
> > OT> configuration file.
> >
> > OT> The worry I have with the second approach is that it means that the
> > OT> font installation process has to be very tightly coupled to Pango,
> > OT> and while I hope that Pango will be very widely used, a high level
> > OT> installation complexity would hinder that process.
> >
> > Pango could just maintain a coverage table/database itself. Each time
> > it is called, it just check if there are new fonts not included in
> > its database before doing the lookup stuff. If there are new
> > fonts/shapers or removed fonts/shapers, the database should be
> > updated. There are normally fewer fonts being added in a system after
> > installation, so setting up a coverage table for new fonts should not
> > be too slow. Beside, it is a one time process for each font.
>
> Yes - this is basically what I meant by caching the results when I
> described my first brute-force approach.
>
> There are definitely issues you have to worry about:
>
> - locking
> - knowing when fonts/shapers have been removed
> - providing feedback to the user during time-intensive operations.
>
> (You don't want every GTK+ program on your system to inexplicably lock
> up for 30 seconds when you install the Tamil shaper package.)
>
> But it is a very reasonable approach.
>
> Thanks for the input,
> Owen
I don't really see the problem with looking up the shaper's coverage. Why not
simply have a call to the shaper which returns its coverage as a bitmap? The
real problem is the fonts. Many East Asian fonts don't provide full coverage
either UniHan, or any national sub-set of UniHan. With Unicode 3 nearing
release this will get much worse (though hopefully only for a while). Testing
the font's coverage is the stinker. Introducing a new mechanism to provide a
rapid test of font coverage would be difficult.
Steve
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]