Re: Looking up fonts and shapers in Pango

[Owen Taylor <otaylor redhat com>]

Steve Underwood <steveu@coppice.org> writes:

> 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 reason why not is that the coverage of a shaper depends on the coverage
of the fonts it is using. 

So, instead of getting the coverage of the shaper, there will be the
call to get the coverage of the font, and as you say, fonts are typically
sparse, 

> 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.

Well, difficult, but I don't think insoluable. Basically, for X, you
need to load the font to find out its coverage; making that rapid may
require a cache.

Regards,
                                        Owen