Re: Looking up fonts and shapers in Pango



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]