Problem with narrow vs condensed fonts

Problem with narrow vs condensed fonts

[Stefan Monnier]

My Emacs by default fails to show me the variable-pitch face.
I tracked it down to the following problem:

My default font is misc-fixed-semicondensed-13, and on my system I have
some adobe-helvetica-narrow fonts.  Since semicondensed=87 and
narrow=75 (and normal is 100), Emacs decided to prefer
adobe-helvetica-narrow over adobe-helvetica-normal.  But by the time
this choice is made we don't have XLFD font names any more but font
entities, so the spec just say "swidth=75" and when we try to open the
font that we just listed this fails because 75 is translated back to
"condensed" rather than to "narrow".

In essence font-swidth-table needs to be bijective but isn't.
By changing "narrow"'s setting from 75 to 76 (so it doesn't get the
same value as any other any more) the problem disappears (and another
problem shows up: I now get this narrow font where I'd prefer the
normal font since helvetica is already pretty narrow).

Does this make sense?  Should we fix font-swidth-table and friends (and
change internal-set-font-style-table to check that the tables are indeed
bijective)?


        Stefan

Re: Problem with narrow vs condensed fonts

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
> Does this make sense?  Should we fix font-swidth-table and friends (and
> change internal-set-font-style-table to check that the tables are indeed
> bijective)?


I do not know the code, but from what you wrote it looks like 
font-swidth-table has a double duty: synonym table and name <-> number.

The latter use obviously must be bijective (and can't coexist with the 
first).

But maybe the translation of semicondensed to a number should be 
deferred? (I have no idea, just trying to digest what you wrote.)

Re: Problem with narrow vs condensed fonts

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Does this make sense?  Should we fix font-swidth-table and friends (and
> change internal-set-font-style-table to check that the tables are indeed
> bijective)?

That completely breaks font section.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Problem with narrow vs condensed fonts

[Stefan Monnier]

>> Does this make sense?  Should we fix font-swidth-table and friends (and
>> change internal-set-font-style-table to check that the tables are indeed
>> bijective)?

> That completely breaks font section.

Sounds great ;-)
What is "font section"?


        Stefan

Re: Problem with narrow vs condensed fonts

[Kenichi Handa]

In article <jwvfxvhaisv.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> Does this make sense?  Should we fix font-swidth-table and friends (and
>>> change internal-set-font-style-table to check that the tables are indeed
>>> bijective)?

> > That completely breaks font section.

> Sounds great ;-)
> What is "font section"?

I found that this change:

2008-02-22  Stefan Monnier  <monnier@iro.umontreal.ca>

	* faces.el (font-weight-table, font-slant-table, font-swidth-table):
	Make those tables bijective.

interacts badly with this change:

2008-02-01  Jason Rumney  <jasonr@gnu.org>

	* font.c (font_parse_fcname): Default weight and slant to normal.

Jason, could you explain why we should set the default
values for weight and slant in font_parse_fcname?

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

Re: Problem with narrow vs condensed fonts

[Jason Rumney]

Kenichi Handa wrote:
> 2008-02-01  Jason Rumney  <jasonr@gnu.org>
>
> 	* font.c (font_parse_fcname): Default weight and slant to normal.
>
> Jason, could you explain why we should set the default
> values for weight and slant in font_parse_fcname?
>   


Without that, the weight and slant were uninitialised, and Emacs was 
randomly opening italic and bold fonts, at least on Windows.

Re: Problem with narrow vs condensed fonts

[Kenichi Handa]

In article <47C27BDF.30001@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> Kenichi Handa wrote:
> > 2008-02-01  Jason Rumney  <jasonr@gnu.org>
> >
> > 	* font.c (font_parse_fcname): Default weight and slant to normal.
> >
> > Jason, could you explain why we should set the default
> > values for weight and slant in font_parse_fcname?
> >   

> Without that, the weight and slant were uninitialised, and Emacs was 
> randomly opening italic and bold fonts, at least on Windows.

On X also, if we start Emacs with, for instance, "-fn
-*-fixed-*--16-*-iso8859-1", Emacs may use an italic font
(even without font-backend), which is the same as xterm.
It's upto the behaviour of font backend.  For instance, with
Xft font-backend, as it uses fontconfig library for font
selection and fontconfig has system wide default preference,
"-fn monospace-12" will results in non-italic, non-bold
font.

If we are going to implement the feature "prefer normal
style font if a user doesn't specify anything", I think it
should be done in the different place, not in
font_parse_fcname.

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

Re: Problem with narrow vs condensed fonts

[Jason Rumney]

Kenichi Handa wrote:
> On X also, if we start Emacs with, for instance, "-fn
> -*-fixed-*--16-*-iso8859-1", Emacs may use an italic font
> (even without font-backend), which is the same as xterm.
>   
Right, but users tend to specify weight and slant with xlfd descriptors, 
and probably wouldn't be surprised to have an omitted slant or weight 
interpreted as a wildcard, while fcname seems to encourage their 
omission for normal fonts: ie users expect "Courier-12" to be equivalent 
to "Courier-12:weight=normal:slant=normal", not 
"Courier-12:weight=*:slant=*".

Re: Problem with narrow vs condensed fonts

[Andreas Schwab]

Kenichi Handa <handa@m17n.org> writes:

> I found that this change:
>
> 2008-02-22  Stefan Monnier  <monnier@iro.umontreal.ca>
>
> 	* faces.el (font-weight-table, font-slant-table, font-swidth-table):
> 	Make those tables bijective.
>
> interacts badly with this change:
>
> 2008-02-01  Jason Rumney  <jasonr@gnu.org>
>
> 	* font.c (font_parse_fcname): Default weight and slant to normal.

Reverting the latter change alone does not fix it.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Problem with narrow vs condensed fonts

[Stefan Monnier]

> I found that this change:
[...]
> interacts badly with this change:

What kind of "bad interaction" are we talking about?


        Stefan

Re: Problem with narrow vs condensed fonts

[Kenichi Handa]

In article <jwvd4ql6ny5.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

> > I found that this change:
> [...]
> > interacts badly with this change:

> What kind of "bad interaction" are we talking about?

Jason's change is to set the weight to `normal' when a user
doesn't specify then fontconfig-style font name.  So, Emacs
tries find a font exactly matching with `normal' weight.
But, as I put a code to treat fontconfig's numeric values
for `regular (80)', `normal (80)' `medium (100)' the same in
ftfont_list (*), that function had included regular weight
font in the return value even if `normal' weight is
specified.

But, as you changed the numeric value of of `normal' weight
from 100 to 101, ftfont_list doesn't include regular weight
font (most of ttf has regular weight).

(*) This adhoc code is to adjust ftfont_list to what Emacs
(or X fonts) think about normal weight.  The old codes of
xfaces treats `medium' `normal' `regular' the same.

By the way, I have not yet considered well about the problem
of non-"bijective" font-XXX-tables.

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

Re: Problem with narrow vs condensed fonts

[Stefan Monnier]

> But, as you changed the numeric value of of `normal' weight
> from 100 to 101, ftfont_list doesn't include regular weight
> font (most of ttf has regular weight).

Why does it only accept an exact-match?


        Stefan

Re: Problem with narrow vs condensed fonts

[Kenichi Handa]

In article <jwvprukihh9.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > But, as you changed the numeric value of of `normal' weight
> > from 100 to 101, ftfont_list doesn't include regular weight
> > font (most of ttf has regular weight).

> Why does it only accept an exact-match?

Because that's the spec I desided for that API of (struct
font_driver *)->list.  I wanted to distinguish required
(i.e. mandatory) font-spec and preferred font-spec.  `list'
returns fonts matching with a required spec, and
font-selection routine find a font besting matching with
preferred spec from them.

So, we should not give FONT-SPEC containing just preferred
specs to `list'.

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

Re: Problem with narrow vs condensed fonts

[Stefan Monnier]

>> > But, as you changed the numeric value of of `normal' weight
>> > from 100 to 101, ftfont_list doesn't include regular weight
>> > font (most of ttf has regular weight).

>> Why does it only accept an exact-match?

> Because that's the spec I desided for that API of (struct
> font_driver *)->list.  I wanted to distinguish required
> (i.e. mandatory) font-spec and preferred font-spec.  `list'
> returns fonts matching with a required spec, and
> font-selection routine find a font besting matching with
> preferred spec from them.

> So, we should not give FONT-SPEC containing just preferred
> specs to `list'.

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.


        Stefan

Re: Problem with narrow vs condensed fonts

[Stefan Monnier]

>>> > But, as you changed the numeric value of of `normal' weight
>>> > from 100 to 101, ftfont_list doesn't include regular weight
>>> > font (most of ttf has regular weight).

>>> Why does it only accept an exact-match?

>> Because that's the spec I desided for that API of (struct
>> font_driver *)->list.  I wanted to distinguish required
>> (i.e. mandatory) font-spec and preferred font-spec.  `list'
>> returns fonts matching with a required spec, and
>> font-selection routine find a font besting matching with
>> preferred spec from them.

>> So, we should not give FONT-SPEC containing just preferred
>> specs to `list'.

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


        Stefan

Re: Problem with narrow vs condensed fonts

[Jason Rumney]

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

As you can see from the checkin comment, I tried doing this in 
font_score, but it didn't have any effect, 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).

Re: Problem with narrow vs condensed fonts

[Kenichi Handa]

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

Re: Problem with narrow vs condensed fonts

[Jason Rumney]

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.

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.

Re: Problem with narrow vs condensed fonts

[Kenichi Handa]

In article <47C6983E.50503@gnu.org>, Jason Rumney <jasonr@gnu.org> 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
handa@ni.aist.go.jp

In article <47C3FF62.1080003@gnu.org>, Jason Rumney <jasonr@gnu.org> 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
handa@ni.aist.go.jp

Re: Problem with narrow vs condensed fonts

[Angelo Graziosi]

Could this thread be related to these observations [1], [2]?


Cheers,
    Angelo.


---
[1] http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02128.html
[2] http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg02197.html

Facesti come quei che va di notte,
che porta il lume dietro e se' non giova,
ma dopo se' fa le persone dotte.
-- 
                   DANTE, Purgatorio, xxii 67-69