|Subject:||Re: Problem with narrow vs condensed fonts|
|Date:||Thu, 28 Feb 2008 11:17:18 +0000|
|User-agent:||Thunderbird 188.8.131.52 (Windows/20080213)|
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.
|[Prev in Thread]||Current Thread||[Next in Thread]|