bug#17973: Thin space not thin at all

[handa@gnu.org (K. Handa)]

In article <jwv1ttvpvuu.fsf@iro.umontreal.ca>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

>    % emacs-24/src/emacs -Q -fn '-misc-fixed-*-r-semicondensed--13-*-*-*-*-*-*'
>    M-< C-f C-x SPC

> At this point I should see a thin space before the cursor (highlighted
> with the region face).  Instead I see a full space.

>    C-u C-x =

> indeed shows that there's an overlay at point with an after-string of:

>    #(" " 0 1 (face (region (:height 0.2))))

> Now admittedly, ":height 0.2" does not specify a width, but Emacs should
> be able to find a font that's about 2½ pixels high but not
> 6 pixels wide.

> This is related to bug#16403, in that this is probably a long-standing
> bug, but the new rectangular region makes it more visible.
> Maybe it's actually the same bug as bug#9787 as well, which is also more
> visible since *VC-log* uses such a "thin line" to separate the header
> from the body.

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.

To fix this problem, perhaps we must propagate the
information about how font related attributes are merged;
i.e. which one comes from the specific face directly and
which one is inherited from the other faces (including the
default face).  It's not a trivial work.

---
Kenichi Handa
handa@gnu.org