Re: font-backend mechanism on Windows and Mac?

[Kenichi Handa <handa@m17n.org>]

In article <46EB1FB5.40603@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> Adrian Robert wrote:
> > Another possibility is the metrics implementation.  In text_extents()
> > the W32 and Xft impls query the font itself for the metrics every
> > time.  With Xft this may be fast if the font is client-side (and it
> > does it for the whole string, not each char), but possibly under
> > Windows it is not.  In Cocoa nsfont.m metrics are cached in blocks of
> > 256 chars to deal with this.
> This might make a difference, the old Windows code used to cache the
> metrics of ASCII characters for each font.

> > font.c.  (But drivers _should_ do a full-string determination like
> > xftfont.c does if they can, so they wouldn't need it.)
> >   
> I think the lack of comments for the font backend has led us to
> implement this incorrectly.

Which part of comment do you mean?

> Actually, when text_extents is called with a metrics argument, nglyphs
> is always 1, so there is no need to loop over all the characters, and
> there is only one metric to fill in, not an array of them.

In most cases, text_extents is called for one glyph by one.
That is because the original display engine calls
x_produce_glyphs for one character by one.  To improve it,
we will need a very big change in the core part of the
display engine.

But, x_compute_glyph_string_overhangs will call text_extents
with multiple glyphs.

> In the case
> where metrics is NULL, the Windows version does do a full string
> determination, but it has to convert the unsigned array of characters to
> a short array for the Windows API functions.

??? text_extents should always be called with non-NULL
metrics arg.

---
Kenichi Handa
handa@m17n.org