GNU bug report logs - #17973
Thin space not thin at all

Previous Next

Package: emacs;

Reported by: Stefan Monnier <monnier <at> iro.umontreal.ca>

Date: Tue, 8 Jul 2014 20:19:02 UTC

Severity: normal

Merged with 9787, 12556

Found in versions 23.3, 24.2.50, 24.3.92

Done: Stefan Monnier <monnier <at> IRO.UMontreal.CA>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: handa <at> gnu.org (K. Handa)
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 17973 <at> debbugs.gnu.org
Subject: bug#17973: Thin space not thin at all
Date: Thu, 10 Jul 2014 00:32:33 +0900
In article <jwv1ttvpvuu.fsf <at> iro.umontreal.ca>, Stefan Monnier <monnier <at> 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 <at> gnu.org




This bug report was last modified 10 years and 95 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.