Re: Problem with narrow vs condensed fonts

[Jason Rumney]

Jason Rumney wrote:
> 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.
>
> I don't think users will be surprised if numeric weights are defined 
> as backend specific. Perhaps we shouldn't even allow them for the x 
> backend, since they are not supported natively.

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 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.