bug#17973: Thin space not thin at all

[Stefan Monnier <monnier@iro.umontreal.ca>]

forcemerge 9787 17973
thanks

> Yes, I agree that they are all the same bug.  As far as I
> know, the problem is with the mechanism of face attribute
> merging.  When the control reaches the font selection
> function font_find_for_lface, font related attributes
> (family, foundry, weight, ..., height, ...) are already
> merged.  As font_find_for_lface doesn't know which attribute
> to respect more (except for what specified in
> face-font-selection-order), it at first tries to get a list
> of fonts whose family, foundry, registry, adstyle are the
> same as merged attributes, and selects a font most close to
> the specified height.

So, IIUC you're saying that when we get to selecting a font, we have
specifications such as

  family = fixed
  foundry = misc
  height = 2½ pixels

and we end up choosing the 13pixel-high font because it's the only one
that matches "misc-fixed"?  I do have a 6pixel-high misc-fixed font
(tho not semicondensed), so it seems like it's not the
whole explanation.

Or is the "13pixel high" specification kept somewhere (elsewhere than in
the "height", obviously)?

I'm beginning to sense that the "13pixel high" specification is indeed
kept elsewhere, and it is kept so as to avoid other problems I've had in
the past, where the 13pixel spec was turned into a height spec and that
this height spec was then used to look for a font and it occasionally
found *another* font with the same height in points but not in pixels.

Is that right?

OTOH, doing a M-x customize-face REt default RET, then setting family to
`fixed' and foundry to `misc', and then playing with `height' is pretty
scary: height=2000 gives me a 9pixel-high font (!) whereas setting it to
200 gives a more reasonable 20pixel-high font.


        Stefan