[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
address@hidden
- Re: font-backend mechanism on Windows and Mac?, (continued)
- Re: font-backend mechanism on Windows and Mac?, Kenichi Handa, 2007/09/10
- Re: font-backend mechanism on Windows and Mac?, Jason Rumney, 2007/09/10
- Re: font-backend mechanism on Windows and Mac?, Jason Rumney, 2007/09/10
- Re: font-backend mechanism on Windows and Mac?, Kenichi Handa, 2007/09/12
- Re: font-backend mechanism on Windows and Mac?, Kenichi Handa, 2007/09/13
- Re: font-backend mechanism on Windows and Mac?, Jason Rumney, 2007/09/13
- Re: font-backend mechanism on Windows and Mac?, Kenichi Handa, 2007/09/14
- Re: font-backend mechanism on Windows and Mac?, Jason Rumney, 2007/09/14
- Re: font-backend mechanism on Windows and Mac?, Adrian Robert, 2007/09/14
- Re: font-backend mechanism on Windows and Mac?, Jason Rumney, 2007/09/14
- Re: font-backend mechanism on Windows and Mac?,
Kenichi Handa <=
- Re: font-backend mechanism on Windows and Mac?, Jason Rumney, 2007/09/15
- Re: font-backend mechanism on Windows and Mac?, Kenichi Handa, 2007/09/16
- Re: font-backend mechanism on Windows and Mac?, Jason Rumney, 2007/09/16
- Re: font-backend mechanism on Windows and Mac?, Kenichi Handa, 2007/09/16
- Re: font-backend mechanism on Windows and Mac?, Kenichi Handa, 2007/09/14
- Re: font-backend mechanism on Windows and Mac?, Adrian Robert, 2007/09/13
- Re: font-backend mechanism on Windows and Mac?, Jason Rumney, 2007/09/13
- Re: font-backend mechanism on Windows and Mac?, Kenichi Handa, 2007/09/13
- Re: font-backend mechanism on Windows and Mac?, Adrian Robert, 2007/09/14
- Re: font-backend mechanism on Windows and Mac?, YAMAMOTO Mitsuharu, 2007/09/14