From: Stefan Monnier <monnier@iro.umontreal.ca>
To: handa@gnu.org (K. Handa)
Cc: 17973@debbugs.gnu.org
Subject: bug#17973: Thin space not thin at all
Date: Wed, 09 Jul 2014 15:21:16 -0400 [thread overview]
Message-ID: <jwvion6nz07.fsf-monnier+emacsbugs@gnu.org> (raw)
In-Reply-To: <87d2deeeem.fsf@gnu.org> (K. Handa's message of "Thu, 10 Jul 2014 00:32:33 +0900")
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
next prev parent reply other threads:[~2014-07-09 19:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-08 18:07 bug#17973: Thin space not thin at all Stefan Monnier
2014-07-09 15:32 ` K. Handa
2014-07-09 19:21 ` Stefan Monnier [this message]
2014-07-10 14:28 ` K. Handa
2014-07-10 16:37 ` Stefan Monnier
2014-07-13 15:12 ` K. Handa
2014-07-19 6:13 ` Stefan Monnier
2014-07-19 15:57 ` K. Handa
2014-07-19 17:30 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvion6nz07.fsf-monnier+emacsbugs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=17973@debbugs.gnu.org \
--cc=handa@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.