Re: Problem with narrow vs condensed fonts

[Kenichi Handa]

In article <address@hidden>, Jason Rumney <address@hidden> writes:

> I think it would be better if font-spec allowed either symbols or 
> integers for weight, slant and swidth. Only certain symbols 
> (medium/normal/regular, bold, italic, roman) are guaranteed to be 
> supported, other symbols and integer values are implementation specific 
> and should not be used internally by Emacs, or by Lisp packages, but are 
> available to end users to fine tune their face customizations etc.

> The x backend would not recognize integer weights, and would convert 
> symbols for inclusion in xflds by symbol-name.

> The xft, Windows and other backends would have their own tables for 
> converting symbols to numeric values where numeric values are used 
> internally by the implementation.

I was just writing the similar thing.  See the tail.

> I thought the intention of the new font backend was to abstract out the 
> differences between font APIs, but by imposing fontconfig definitions of 
> numeric weight, slant and swidth, we have only moved from a XFLD centric 
> font implementation to a fontconfig centric one.

As far as numeric values and symbolic values has one to one
mapping, passing numeric values and passing symbolic values
has no difference.  Selecting fontconfig's numeric values
was just because they fit in 0..255 (thus the diffs can be
represented by 8-bit), and I didn't have a better idea about
deciding the difference of MEDIUM and DEMIBOLD compared with
the difference of DEMIBOLD and BOLD in font sorting.

Using fontconfig's numeric values may result in a little bit
efficient code in ftfont.c, but I think that is an
acceptable partiality.

---
Kenichi Handa
address@hidden

In article <address@hidden>, Jason Rumney <address@hidden> writes:

> Kenichi Handa wrote:
> > 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?
> >   

> It is probably quite difficult and error prone, as we would be mapping a 
> larger range (100-900 for weight on windows) onto a smaller range 
> (0-210), and the mapping appears to be non-linear. Although in practice, 
> most fonts probably use the fixed values currently defined in 
> font-weight-table, I don't think it is guaranteed.

There's another reason for having common numeric values for
all font-backends.  As it is possible to have multiple
font-backends, to have a correct font sorting, the numeric
values must be consistent.

How about this model?

Emacs has a single fixed mapping of symbolic values vs.
numeric values (e.g. weight:regular<->100,normal<->101).
`list' callback of a font-backend are given a numeric value
and must convert it to each backend's numric value by
considering the symbolic value.

For instance, when ftfont_list is given the spec of
weight:100, it must know that it means regular, convert the
value to FC_WEIGHT_REGULAR, and return fonts of that value
only (but by giving weight:100 to them).

If the matching symbol of the given numeric weight is not
known to the font-backend, font-backend selects the nearest
numeric value.

Fot instance, provided that font-weight-table has the entry
(superbold . 209), and ftfont_list is given the spec of
weight:209, as fontconfig doesn't know about `superbold',
ftont_list finds the nearest symbolic value known to
fontconfig.  That is (black . 210) currently.  So, it
returns fonts of FC_WEIGHT_BLACK (but by giving weight:209
to them).

When the given spec doesn't specify weight, `list' returns
fonts of any weight but adjusting weight numeric values to
one of quantised values listed in font-weight-table.

This way, I think, Emacs can keep consistency in symbolic
and numeric values.

---
Kenichi Handa
address@hidden