[Top][All Lists]

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

Re: font-backend mechanism on Windows and Mac?

From: Kenichi Handa
Subject: Re: font-backend mechanism on Windows and Mac?
Date: Sat, 15 Sep 2007 10:31:06 +0900
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/23.0.0 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

In article <address@hidden>, Jason Rumney <address@hidden> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]