Re: Looking up fonts and shapers in Pango



Pablo Saratxaga wrote:

> Kaixo!
>
> On Mon, Jan 24, 2000 at 04:55:16PM -0500, Owen Taylor wrote:
>
> >> 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,
>
> That is only a problem with fonts whose coverage isn't explicit trough
> their X11 naming. Only unicode fonts are in such case.

This is most untrue for CJK fonts.

> >> 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
>
> On the other hand the CJK fonts have a well established set of glyphs
> that *must* be present.
> So the CJK fonts don't really need testing; we can safely assume they
> include all the glyphs they tell they include (and if not, that particular
> font desserves to be moved to /dev/null)
>
> Then only the fonts listed as *-iso10646-1 and *-*-unicode would require
> to be looked into; that would decrease the time needed to get the coverage
> of all fonts, as only a small subset of them would need to be opened.
> (and we could even go further for some *-*-unicode, as *-ethiopic-unicode,
> and assume they only cover what they tell they cover and not open them)

This is totally untrue, for both the older encodings and Unicode CJK fonts. For
example, Big-5 has over 13,000 characters, but many Big-5 fonts only implement
about half those characters. The implemented characters are very inconsistent
between fonts, too. Only the common fonts can be guaranteed to have the whole set.
For Unicode fonts, which I believe must become the norm for CJK as Unicode 3 rolls
out, you haven't much of a clue which characters will and won't be present.

Steve.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]