Re: Problem with narrow vs condensed fonts

[Kenichi Handa <handa@m17n.org>]

In article <47C3DFD7.4030406@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> Stefan Monnier wrote:
>>> Right: the defaulting to "normal" should be done when the value is later
>>> used as a preferred spec, but a wildcard should be used instead if the
>>> value is later used as an exact spec.
>>> 
> >
> > Or rather the defaulting to "normal" should be done elsewhere: when
> > choosing the preferred font for a SPEC which doesn't specify any weight.

Oops, I've forgotten that I've already implemented a code
preferring "normal" style if not specified.  It in the
function font_open_by_name.  This function is called to open
a font specified by name.  It builds two font-specs,
requested (from the font name) and preferred (having
"normal" styles), and calls Flist_fonts.  Flist_fonts lists
all fonts exactly matching with the requested spec, then
sorts them by considering preferred spec.

> As you can see from the checkin comment, I tried doing this in 
> font_score, but it didn't have any effect,

Ah, I didn't notice that change.

> so I ended up making the 
> change right at the beginning of the font selection process in 
> font_parse_fcname. I left the change in font_score even though it didn't 
> work, because it seemed right to prefer normal fonts there if weight and 
> slant were unspecified (and presumably adstyle).

For x and xft backend, it seems that the algorithm of
font_open_by_name works well.  Could you please check why it
doesn't work for Windows font-backend?

By the way, I think having different numeric values for
Windows is not right.  The function font-spec accepts also
numeric values for style parameters (:weight, :slant,
:width).  So, it is better that the numeric values are
consistent in all versions of Emacs.  Is it difficult (or
time consuming) to map windows numeric values to what
specified in font-XXX-table in w32_enumfont_pattern_entity?

---
Kenichi Handa
handa@ni.aist.go.jp