unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#57962: 29.0.50; Odd font choices
@ 2022-09-20 22:16 Lars Ingebrigtsen
  2022-09-21  2:19 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 29+ messages in thread
From: Lars Ingebrigtsen @ 2022-09-20 22:16 UTC (permalink / raw)
  To: 57962

[-- Attachment #1: Type: text/plain, Size: 121 bytes --]


I'm not sure when this started happening, but probably not more than a
month ago.

An image to illustrate the problem:


[-- Attachment #2: Type: image/png, Size: 17301 bytes --]

[-- Attachment #3: Type: text/plain, Size: 2013 bytes --]


From "emacs -Q" (but not with my normal font choices), the font used for
the help-key-binding face is larger than the rest of the text, making
various things kinda ugly.

The normal text uses:

    ftcrhb:-DAMA-Ubuntu Mono-regular-normal-normal-*-45-*-*-*-m-0-iso10646-1 (#x55)

The keyboard text is:

    ftcrhb:-PfEd-DejaVu Sans Mono-regular-normal-normal-*-45-*-*-*-m-0-iso10646-1 (#x52)

And the help-key-binding face is:

(defface help-key-binding
  '((((class color) (min-colors 88) (background light))
[...]
     :inherit fixed-pitch)

and

(defface fixed-pitch
  '((t :family "Monospace"))
  "The basic fixed-pitch face."
  :group 'basic-faces)

So this chooses a different font than

(defface default
  '((t nil)) ; If this were nil, face-defface-spec would not be set.
  "Basic default face."
  :group 'basic-faces)

?

Hm...  but on the other hand, perhaps I started seeing this because I
switched from Debian to Ubuntu?  I'm seeing the same in Emacs 28 if I
use the fixed-pitch face there (but in Emacs 28, help-key-binding
doesn't inherit from fixed-pitch).

So it's possibly that we've just never noticed before, because we
haven't used `fixed-pitch' in these contexts before.

In any case, it's unfortunate that it doesn't look very pleasant with
"emacs -Q" in a major distribution like Ubuntu, so I think we should do
something, but I'm not sure what.



In GNU Emacs 29.0.50 (build 61, x86_64-pc-linux-gnu, GTK+ Version
 3.24.33, cairo version 1.16.0) of 2022-09-16 built on joga
Repository revision: 7d39453fd64e355526291b0ca5672e838de5fb58
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101003
System Description: Ubuntu 22.04.1 LTS

Configured using:
 'configure -C'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-09-20 22:16 bug#57962: 29.0.50; Odd font choices Lars Ingebrigtsen
@ 2022-09-21  2:19 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-09-21 10:43   ` Lars Ingebrigtsen
  0 siblings, 1 reply; 29+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-09-21  2:19 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 57962

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I'm not sure when this started happening, but probably not more than a
> month ago.
>
> An image to illustrate the problem:
>
>
>
>
>>From "emacs -Q" (but not with my normal font choices), the font used for
> the help-key-binding face is larger than the rest of the text, making
> various things kinda ugly.
>
> The normal text uses:
>
>     ftcrhb:-DAMA-Ubuntu Mono-regular-normal-normal-*-45-*-*-*-m-0-iso10646-1 (#x55)
>
> The keyboard text is:
>
>     ftcrhb:-PfEd-DejaVu Sans Mono-regular-normal-normal-*-45-*-*-*-m-0-iso10646-1 (#x52)
>
> And the help-key-binding face is:
>
> (defface help-key-binding
>   '((((class color) (min-colors 88) (background light))
> [...]
>      :inherit fixed-pitch)
>
> and
>
> (defface fixed-pitch
>   '((t :family "Monospace"))
>   "The basic fixed-pitch face."
>   :group 'basic-faces)
>
> So this chooses a different font than
>
> (defface default
>   '((t nil)) ; If this were nil, face-defface-spec would not be set.
>   "Basic default face."
>   :group 'basic-faces)
>
> ?

Yes, "Monospace" is mapped to a special font family by fontconfig,
sometimes different than the monospace font specified via xsettings.

I think the best thing to do would be to change fixed-pitch to be
affected by xsettings as well, but I'm not quite sure how to go about
doing that.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-09-21  2:19 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-09-21 10:43   ` Lars Ingebrigtsen
  2022-10-14 11:41     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 29+ messages in thread
From: Lars Ingebrigtsen @ 2022-09-21 10:43 UTC (permalink / raw)
  To: Po Lu; +Cc: 57962

Po Lu <luangruo@yahoo.com> writes:

> Yes, "Monospace" is mapped to a special font family by fontconfig,
> sometimes different than the monospace font specified via xsettings.
>
> I think the best thing to do would be to change fixed-pitch to be
> affected by xsettings as well, but I'm not quite sure how to go about
> doing that.

Yes, that sounds like a promising direction to go in.  Anybody know how?





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-09-21 10:43   ` Lars Ingebrigtsen
@ 2022-10-14 11:41     ` Lars Ingebrigtsen
  2022-10-14 11:53       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-10-14 12:07       ` Eli Zaretskii
  0 siblings, 2 replies; 29+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-14 11:41 UTC (permalink / raw)
  To: Po Lu; +Cc: 57962

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> Yes, "Monospace" is mapped to a special font family by fontconfig,
>> sometimes different than the monospace font specified via xsettings.
>>
>> I think the best thing to do would be to change fixed-pitch to be
>> affected by xsettings as well, but I'm not quite sure how to go about
>> doing that.
>
> Yes, that sounds like a promising direction to go in.  Anybody know how?

We have to get this fixed, one way or another, because we can't have
Emacs looking this bad on a popular platform like Ubuntu.

So -- we're using the `fixed-pitch' face for keyboard stuff because the
`default' font may well use a proportional font.  (It's unusual, but
feasible.)

But in the common case, where `default' uses a fixed width font, then I
think the `fixed-pitch' face should use exactly the same font.

Is there some easy way to achieve this, by any chance?





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-14 11:41     ` Lars Ingebrigtsen
@ 2022-10-14 11:53       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-10-14 12:02         ` Lars Ingebrigtsen
  2022-10-14 12:07       ` Eli Zaretskii
  1 sibling, 1 reply; 29+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-14 11:53 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 57962

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So -- we're using the `fixed-pitch' face for keyboard stuff because the
> `default' font may well use a proportional font.  (It's unusual, but
> feasible.)
>
> But in the common case, where `default' uses a fixed width font, then I
> think the `fixed-pitch' face should use exactly the same font.
>
> Is there some easy way to achieve this, by any chance?

BTW, does changing the definition of fixed-pitch to read:

  "monospace-10"

solve anything?





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-14 11:53       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-14 12:02         ` Lars Ingebrigtsen
  2022-10-14 12:05           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 29+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-14 12:02 UTC (permalink / raw)
  To: Po Lu; +Cc: 57962

[-- Attachment #1: Type: text/plain, Size: 293 bytes --]

Po Lu <luangruo@yahoo.com> writes:

> BTW, does changing the definition of fixed-pitch to read:
>
>   "monospace-10"
>
> solve anything?

Just to:

(defface fixed-pitch
  '((t :family "monospace-10"))
  "The basic fixed-pitch face."
  :group 'basic-faces)

?

It changes, but it's still bad:


[-- Attachment #2: Type: image/png, Size: 15923 bytes --]

[-- Attachment #3: Type: text/plain, Size: 88 bytes --]


I.e., it's not just the size difference, but also that they use
different font shapes.

^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-14 12:02         ` Lars Ingebrigtsen
@ 2022-10-14 12:05           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-10-14 12:13             ` Lars Ingebrigtsen
  0 siblings, 1 reply; 29+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-14 12:05 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 57962

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Just to:
>
> (defface fixed-pitch
>   '((t :family "monospace-10"))
>   "The basic fixed-pitch face."
>   :group 'basic-faces)
>
> ?

Yes.

> I.e., it's not just the size difference, but also that they use
> different font shapes.

What happens if you try setting it to each of the following in order?
(The list below was taken straight from xfns.c.)

#if defined USE_CAIRO || defined HAVE_XFT
	    /* This will find the normal Xft font.  */
 	    "monospace-10",
#endif
	    "-adobe-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-1",
	    "-misc-fixed-medium-r-normal-*-*-140-*-*-c-*-iso8859-1",
	    "-*-*-medium-r-normal-*-*-140-*-*-c-*-iso8859-1",
	    /* This was formerly the first thing tried, but it finds
	       too many fonts and takes too long.  */
	    "-*-*-medium-r-*-*-*-*-*-*-c-*-iso8859-1",
	    /* If those didn't work, look for something which will
	       at least work.  */
	    "-*-fixed-*-*-*-*-*-140-*-*-c-*-iso8859-1",
	    "fixed",

It's a long shot, but if it still doesn't work then I'm really out of
ideas.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-14 11:41     ` Lars Ingebrigtsen
  2022-10-14 11:53       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-14 12:07       ` Eli Zaretskii
  2022-10-14 12:18         ` Lars Ingebrigtsen
  1 sibling, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2022-10-14 12:07 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: luangruo, 57962

> Cc: 57962@debbugs.gnu.org
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Fri, 14 Oct 2022 13:41:12 +0200
> 
> So -- we're using the `fixed-pitch' face for keyboard stuff because the
> `default' font may well use a proportional font.  (It's unusual, but
> feasible.)
> 
> But in the common case, where `default' uses a fixed width font, then I
> think the `fixed-pitch' face should use exactly the same font.

It depends on whether we want the fixed-pitch face to look differently
from the default face, even when the default face uses a monospaced
font.  I always thought that fixed-pitch face was supposed to look
differently.

> Is there some easy way to achieve this, by any chance?

Did you try using font-spec with (:spacing 'mono) ?





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-14 12:05           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-14 12:13             ` Lars Ingebrigtsen
  2022-10-14 12:20               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 29+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-14 12:13 UTC (permalink / raw)
  To: Po Lu; +Cc: 57962

Po Lu <luangruo@yahoo.com> writes:

> What happens if you try setting it to each of the following in order?
> (The list below was taken straight from xfns.c.)
>
> #if defined USE_CAIRO || defined HAVE_XFT
> 	    /* This will find the normal Xft font.  */
>  	    "monospace-10",
> #endif
> 	    "-adobe-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-1",
> 	    "-misc-fixed-medium-r-normal-*-*-140-*-*-c-*-iso8859-1",
> 	    "-*-*-medium-r-normal-*-*-140-*-*-c-*-iso8859-1",
> 	    /* This was formerly the first thing tried, but it finds
> 	       too many fonts and takes too long.  */
> 	    "-*-*-medium-r-*-*-*-*-*-*-c-*-iso8859-1",
> 	    /* If those didn't work, look for something which will
> 	       at least work.  */
> 	    "-*-fixed-*-*-*-*-*-140-*-*-c-*-iso8859-1",
> 	    "fixed",
>
> It's a long shot, but if it still doesn't work then I'm really out of
> ideas.

Well, the font Emacs has chosen for `default' is "-DAMA-Ubuntu
Mono-regular-normal-normal-*-45-*-*-*-m-0-iso10646-1", so if I say

(defface fixed-pitch
  '((t :font "-DAMA-Ubuntu Mono-regular-normal-normal-*-45-*-*-*-m-0-iso10646-1"))
  "The basic fixed-pitch face."
  :group 'basic-faces)

then things look fine, of course.  But we want that to happen
automatically (if `default' is using a fixed pitch font).

I.e., if something like this was possible:

(defface fixed-pitch
  '((fixed-width-p default) :inherit default)
    (t :family "Monospace"))
  "The basic fixed-pitch face."
  :group 'basic-faces)

then that is what we'd want, I think?  But I don't think we can say
something like that, can we?

Hm, I should remind myself how those defface predicates work...





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-14 12:07       ` Eli Zaretskii
@ 2022-10-14 12:18         ` Lars Ingebrigtsen
  2022-10-14 12:37           ` Eli Zaretskii
  0 siblings, 1 reply; 29+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-14 12:18 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: luangruo, 57962

Eli Zaretskii <eliz@gnu.org> writes:

> It depends on whether we want the fixed-pitch face to look differently
> from the default face, even when the default face uses a monospaced
> font.  I always thought that fixed-pitch face was supposed to look
> differently.

We haven't really used the fixed-pitch face for much before, but we're
now using it for the face used when displaying key bindings, so it's
shown all over the place in Emacs 29.  

>> Is there some easy way to achieve this, by any chance?
>
> Did you try using font-spec with (:spacing 'mono) ?

In the fixed-pitch defface?  It's already got mono spacing, so I'm not
sure what that would achieve?  If this is what you meant, it has no
effect:

(defface fixed-pitch
  '((t :family "Monospace" :spacing mono))
  "The basic fixed-pitch face."
  :group 'basic-faces)





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-14 12:13             ` Lars Ingebrigtsen
@ 2022-10-14 12:20               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 29+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-14 12:20 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 57962

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> What happens if you try setting it to each of the following in order?
>> (The list below was taken straight from xfns.c.)
>>
>> #if defined USE_CAIRO || defined HAVE_XFT
>> 	    /* This will find the normal Xft font.  */
>>  	    "monospace-10",
>> #endif
>> 	    "-adobe-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-1",
>> 	    "-misc-fixed-medium-r-normal-*-*-140-*-*-c-*-iso8859-1",
>> 	    "-*-*-medium-r-normal-*-*-140-*-*-c-*-iso8859-1",
>> 	    /* This was formerly the first thing tried, but it finds
>> 	       too many fonts and takes too long.  */
>> 	    "-*-*-medium-r-*-*-*-*-*-*-c-*-iso8859-1",
>> 	    /* If those didn't work, look for something which will
>> 	       at least work.  */
>> 	    "-*-fixed-*-*-*-*-*-140-*-*-c-*-iso8859-1",
>> 	    "fixed",
>>
>> It's a long shot, but if it still doesn't work then I'm really out of
>> ideas.
>
> Well, the font Emacs has chosen for `default' is "-DAMA-Ubuntu
> Mono-regular-normal-normal-*-45-*-*-*-m-0-iso10646-1", so if I say
>
> (defface fixed-pitch
>   '((t :font "-DAMA-Ubuntu Mono-regular-normal-normal-*-45-*-*-*-m-0-iso10646-1"))
>   "The basic fixed-pitch face."
>   :group 'basic-faces)
>
> then things look fine, of course.  But we want that to happen
> automatically (if `default' is using a fixed pitch font).

Yes, of course.  I have no idea how the default font is looked up, but
the list I sent is the list of defaults xfns.c tries if xsettings aren't
on (I thought font-use-system-font was on by default, but I was mistaken
there.)





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-14 12:18         ` Lars Ingebrigtsen
@ 2022-10-14 12:37           ` Eli Zaretskii
  2022-10-14 12:48             ` Lars Ingebrigtsen
  0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2022-10-14 12:37 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: luangruo, 57962

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  57962@debbugs.gnu.org
> Date: Fri, 14 Oct 2022 14:18:15 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It depends on whether we want the fixed-pitch face to look differently
> > from the default face, even when the default face uses a monospaced
> > font.  I always thought that fixed-pitch face was supposed to look
> > differently.
> 
> We haven't really used the fixed-pitch face for much before

We use it in info.el for the symbols.

> > Did you try using font-spec with (:spacing 'mono) ?
> 
> In the fixed-pitch defface?  It's already got mono spacing, so I'm not
> sure what that would achieve?  If this is what you meant, it has no
> effect:
> 
> (defface fixed-pitch
>   '((t :family "Monospace" :spacing mono))
>   "The basic fixed-pitch face."
>   :group 'basic-faces)

"No effect" in the sense that if the default face uses a proportional
font, fixed-pitch defined as above still uses a proportional font?

I actually meant something like this:

  (defface fixed-pitch
    `((t :font ,(font-spec :spacing 'M)))
    "The basic fixed-pitch face."
    :group 'basic-faces)





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-14 12:37           ` Eli Zaretskii
@ 2022-10-14 12:48             ` Lars Ingebrigtsen
  2022-10-14 13:00               ` Eli Zaretskii
  0 siblings, 1 reply; 29+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-14 12:48 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: luangruo, 57962

[-- Attachment #1: Type: text/plain, Size: 147 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

> We use it in info.el for the symbols.

Hm...  and there it makes sense to have a different font, perhaps:


[-- Attachment #2: Type: image/png, Size: 77284 bytes --]

[-- Attachment #3: Type: text/plain, Size: 893 bytes --]


Using a different font here makes it stand out in a nice way.  But note
different x heights that makes the line spacing uneven and rather ugly,
so it's not ideal here, either.

>> (defface fixed-pitch
>>   '((t :family "Monospace" :spacing mono))
>>   "The basic fixed-pitch face."
>>   :group 'basic-faces)
>
> "No effect" in the sense that if the default face uses a proportional
> font, fixed-pitch defined as above still uses a proportional font?

It makes no difference either way, whether `default' uses a fixed-width
font or not -- the `fixed-pitch' font uses "Monospace", which is a
fixed-width font.

> I actually meant something like this:
>
>   (defface fixed-pitch
>     `((t :font ,(font-spec :spacing 'M)))
>     "The basic fixed-pitch face."
>     :group 'basic-faces)

That leads to:

Don't know how to purify: #<font-spec nil nil nil nil nil nil nil nil nil nil 100 nil nil>

^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-14 12:48             ` Lars Ingebrigtsen
@ 2022-10-14 13:00               ` Eli Zaretskii
  2022-10-14 13:06                 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2022-10-14 13:00 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: luangruo, 57962

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  57962@debbugs.gnu.org
> Date: Fri, 14 Oct 2022 14:48:20 +0200
> 
> >> (defface fixed-pitch
> >>   '((t :family "Monospace" :spacing mono))
> >>   "The basic fixed-pitch face."
> >>   :group 'basic-faces)
> >
> > "No effect" in the sense that if the default face uses a proportional
> > font, fixed-pitch defined as above still uses a proportional font?
> 
> It makes no difference either way, whether `default' uses a fixed-width
> font or not -- the `fixed-pitch' font uses "Monospace", which is a
> fixed-width font.

But it produces a font different from the default face's font, which
AFAIU was what you wanted?  That's what happens for me: if I start
Emacs with "emacs -fn FOO" where FOO is a variable-pitch font, then
using the defface form I suggested makes fixed-pitch use a monospaced
font.

> >   (defface fixed-pitch
> >     `((t :font ,(font-spec :spacing 'M)))
> >     "The basic fixed-pitch face."
> >     :group 'basic-faces)
> 
> That leads to:
> 
> Don't know how to purify: #<font-spec nil nil nil nil nil nil nil nil nil nil 100 nil nil>

I only tried that in a running Emacs session, and with a face whose
name is different from fixed-pitch.  I haven't tried bootstrapping
with the above in faces.el.  I'm sure we can avoid the problem, if the
effect is what we want: for example, we could have the defface in
startup.el or something.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-14 13:00               ` Eli Zaretskii
@ 2022-10-14 13:06                 ` Lars Ingebrigtsen
  2022-10-14 13:09                   ` Eli Zaretskii
  0 siblings, 1 reply; 29+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-14 13:06 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: luangruo, 57962

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:

> But it produces a font different from the default face's font, which
> AFAIU was what you wanted?

When the default font is proportional; sure.  Otherwise not, I think.

> That's what happens for me: if I start Emacs with "emacs -fn FOO"
> where FOO is a variable-pitch font, then using the defface form I
> suggested makes fixed-pitch use a monospaced font.

Doesn't that happen without the ":spacing mono", too?

>> >   (defface fixed-pitch
>> >     `((t :font ,(font-spec :spacing 'M)))
>> >     "The basic fixed-pitch face."
>> >     :group 'basic-faces)
>> 
>> That leads to:
>> 
>> Don't know how to purify: #<font-spec nil nil nil nil nil nil nil
>> nil nil nil 100 nil nil>
>
> I only tried that in a running Emacs session, and with a face whose
> name is different from fixed-pitch.  I haven't tried bootstrapping
> with the above in faces.el.  I'm sure we can avoid the problem, if the
> effect is what we want: for example, we could have the defface in
> startup.el or something.

I tried it in a running Emacs, but the problem remains -- the
fixed-pitch font is different from default, which is the problem this
bug report is about.

And...  it made it use a proportional font?


[-- Attachment #2: Type: image/png, Size: 29369 bytes --]

^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-14 13:06                 ` Lars Ingebrigtsen
@ 2022-10-14 13:09                   ` Eli Zaretskii
  2022-10-16 10:58                     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2022-10-14 13:09 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: luangruo, 57962

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  57962@debbugs.gnu.org
> Date: Fri, 14 Oct 2022 15:06:25 +0200
> 
> > I only tried that in a running Emacs session, and with a face whose
> > name is different from fixed-pitch.  I haven't tried bootstrapping
> > with the above in faces.el.  I'm sure we can avoid the problem, if the
> > effect is what we want: for example, we could have the defface in
> > startup.el or something.
> 
> I tried it in a running Emacs, but the problem remains -- the
> fixed-pitch font is different from default, which is the problem this
> bug report is about.
> 
> And...  it made it use a proportional font?

Then I have no idea what happens there.  IWFM.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-14 13:09                   ` Eli Zaretskii
@ 2022-10-16 10:58                     ` Lars Ingebrigtsen
  2022-10-16 11:17                       ` Eli Zaretskii
  0 siblings, 1 reply; 29+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-16 10:58 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: luangruo, 57962

I've poked around some more here, experimenting with different fonts
with -fn, and the thing is that everything works as expected with most
fonts (i.e., the height of `fixed-pitch' and `default' fonts are the
same, which is the problem, really) -- but with the default font in
Ubuntu, "Ubuntu Mono", that's not the case.

So Emacs has chosen these two fonts for `default' and `fixed-pitch',
respectively:

    ftcrhb:-DAMA-Ubuntu Mono-regular-normal-normal-*-48-*-*-*-m-0-iso10646-1 (#x2C)
    ftcrhb:-PfEd-DejaVu Sans Mono-regular-normal-normal-*-48-*-*-*-m-0-iso10646-1 (#x26)

Is there something more Emacs could be doing to try to ensure that it
picks equal-sized fonts?  By somehow looking at actual font metrics?  (I
guess we're currently just saying "give me this font in size 48"?  And
that the actual size of the glyphs may vary between fonts?)






^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-16 10:58                     ` Lars Ingebrigtsen
@ 2022-10-16 11:17                       ` Eli Zaretskii
  2022-10-16 12:19                         ` Lars Ingebrigtsen
  0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2022-10-16 11:17 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: luangruo, 57962

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  57962@debbugs.gnu.org
> Date: Sun, 16 Oct 2022 12:58:18 +0200
> 
> I've poked around some more here, experimenting with different fonts
> with -fn, and the thing is that everything works as expected with most
> fonts (i.e., the height of `fixed-pitch' and `default' fonts are the
> same, which is the problem, really) -- but with the default font in
> Ubuntu, "Ubuntu Mono", that's not the case.
> 
> So Emacs has chosen these two fonts for `default' and `fixed-pitch',
> respectively:
> 
>     ftcrhb:-DAMA-Ubuntu Mono-regular-normal-normal-*-48-*-*-*-m-0-iso10646-1 (#x2C)
>     ftcrhb:-PfEd-DejaVu Sans Mono-regular-normal-normal-*-48-*-*-*-m-0-iso10646-1 (#x26)
> 
> Is there something more Emacs could be doing to try to ensure that it
> picks equal-sized fonts?  By somehow looking at actual font metrics?

When we select a suitable font, we generally avoid opening a font,
because that's expensive.  So looking at the metrics is not possible,
unless we actually open each font.

But I don't think I understand what is going on here: these two fonts
are of the same size -- 48 -- so how come the glyphs have different
sizes?  And how different are they?  Can you look at the character
metrics inside gui_produce_glyphs and tell what we get from each font?

> (I guess we're currently just saying "give me this font in size 48"?

I think so, yes.  But if the font spec doesn't specify a size, maybe
we get different sizes?  Although the fact that both are "48" seems to
say we do get the same size?

> And that the actual size of the glyphs may vary between fonts?)

Not sure how this can happen, but I'm not enough of an expert on
fonts, sorry.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-16 11:17                       ` Eli Zaretskii
@ 2022-10-16 12:19                         ` Lars Ingebrigtsen
  2022-10-16 13:53                           ` Eli Zaretskii
  0 siblings, 1 reply; 29+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-16 12:19 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: luangruo, 57962

Eli Zaretskii <eliz@gnu.org> writes:

> When we select a suitable font, we generally avoid opening a font,
> because that's expensive.  So looking at the metrics is not possible,
> unless we actually open each font.

Right...  but after opening a font, we could determine that it was
unsuitable at that point, and then choose another.  That way the happy
path would still be fast.

> But I don't think I understand what is going on here: these two fonts
> are of the same size -- 48 -- so how come the glyphs have different
> sizes?  And how different are they?  Can you look at the character
> metrics inside gui_produce_glyphs and tell what we get from each font?

I haven't, but if I emacs -geometry 80x10 -fn "DejaVu Sans Mono-15" -Q,
I get an Emacs frame that is 2508x762 pixels.  With -fn "Ubuntu Mono-15"
I get a frame that's 2128x662 pixels, so DejaVu Sans Mono is about 18%
larger than Ubuntu Mono, which is noticeable, and makes mixing the two
fonts non-ideal.






^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-16 12:19                         ` Lars Ingebrigtsen
@ 2022-10-16 13:53                           ` Eli Zaretskii
  2022-10-17  9:57                             ` Lars Ingebrigtsen
  0 siblings, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2022-10-16 13:53 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: luangruo, 57962

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  57962@debbugs.gnu.org
> Date: Sun, 16 Oct 2022 14:19:03 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > When we select a suitable font, we generally avoid opening a font,
> > because that's expensive.  So looking at the metrics is not possible,
> > unless we actually open each font.
> 
> Right...  but after opening a font, we could determine that it was
> unsuitable at that point, and then choose another.  That way the happy
> path would still be fast.

If we open the font soon enough after deciding it's what we want, yes.

> > But I don't think I understand what is going on here: these two fonts
> > are of the same size -- 48 -- so how come the glyphs have different
> > sizes?  And how different are they?  Can you look at the character
> > metrics inside gui_produce_glyphs and tell what we get from each font?
> 
> I haven't, but if I emacs -geometry 80x10 -fn "DejaVu Sans Mono-15" -Q,
> I get an Emacs frame that is 2508x762 pixels.  With -fn "Ubuntu Mono-15"
> I get a frame that's 2128x662 pixels, so DejaVu Sans Mono is about 18%
> larger than Ubuntu Mono, which is noticeable, and makes mixing the two
> fonts non-ideal.

Strange.  But I'm not sure I understand the meaning of the 48 think in
the font's XLFD signature.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-16 13:53                           ` Eli Zaretskii
@ 2022-10-17  9:57                             ` Lars Ingebrigtsen
  2022-10-17 10:22                               ` Eli Zaretskii
  2022-10-17 14:20                               ` Stefan Kangas
  0 siblings, 2 replies; 29+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-17  9:57 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: luangruo, 57962, Stefan Kangas

Eli Zaretskii <eliz@gnu.org> writes:

> Strange.  But I'm not sure I understand the meaning of the 48 think in
> the font's XLFD signature.

After googling "difference in font sizes", it's reminded me what I knew
before, but had apparently suppressed -- those numbers don't really mean
much, and actual font sizes just vary according to the font designers'
whims.

So there is no way to say "I have font X, give me font Y of the same
size".

So I think we just have to mitigate this on a practical level, and the
practical problem we have is that we expect a (fixed pitch) `default' font
to have the same size as the `help-key-binding' font, since we mix these
faces so much in our displays, and we want them to line up in tabular
outputs.

This means that we can either remove ":inherit fixed-pitch" from the
latter face -- and that would fix the problem in 99.7% of the cases.
But ideally, we'd like to have that face be fixed-pitch even if
`default' uses a proportional font (which is possibly, but very very
unusual).  To achieve that we'd have to implement something like

  :inherit (if (monospacep 'default) 'default 'fixed-pitch)

or something?

Or any other ideas?  (I've added Stefan K to the CCs; perhaps he has
ideas here.)





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-17  9:57                             ` Lars Ingebrigtsen
@ 2022-10-17 10:22                               ` Eli Zaretskii
  2022-10-17 11:35                                 ` Lars Ingebrigtsen
  2022-10-17 14:20                               ` Stefan Kangas
  1 sibling, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2022-10-17 10:22 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: luangruo, 57962, stefankangas

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  57962@debbugs.gnu.org, Stefan Kangas
>  <stefankangas@gmail.com>
> Date: Mon, 17 Oct 2022 11:57:12 +0200
> 
> So there is no way to say "I have font X, give me font Y of the same
> size".

Maybe with "fixed-*" fonts this is so.  But isn't True Type fonts
scalable, so that we can request any size and get what we request?

> So I think we just have to mitigate this on a practical level, and the
> practical problem we have is that we expect a (fixed pitch) `default' font
> to have the same size as the `help-key-binding' font, since we mix these
> faces so much in our displays, and we want them to line up in tabular
> outputs.
> 
> This means that we can either remove ":inherit fixed-pitch" from the
> latter face -- and that would fix the problem in 99.7% of the cases.
> But ideally, we'd like to have that face be fixed-pitch even if
> `default' uses a proportional font (which is possibly, but very very
> unusual).  To achieve that we'd have to implement something like
> 
>   :inherit (if (monospacep 'default) 'default 'fixed-pitch)
> 
> or something?

Is that because ":spacing 'm" doesn't work (it seems to work for me)?
If so, I think we should try fixing that instead of introducing new
wizardry.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-17 10:22                               ` Eli Zaretskii
@ 2022-10-17 11:35                                 ` Lars Ingebrigtsen
  2022-10-17 12:58                                   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-10-17 14:26                                   ` Eli Zaretskii
  0 siblings, 2 replies; 29+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-17 11:35 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: luangruo, 57962, stefankangas

Eli Zaretskii <eliz@gnu.org> writes:

> Maybe with "fixed-*" fonts this is so.  But isn't True Type fonts
> scalable, so that we can request any size and get what we request?

We can request "size 12", but how big that is varies greatly by font,
unfortunately.  The font people haven't standarised this -- because of
the origins of font tech, and that "optical size" can vary even with the
same physical sizes.  So it's a mess, basically.

> Is that because ":spacing 'm" doesn't work (it seems to work for me)?
> If so, I think we should try fixing that instead of introducing new
> wizardry.

This:

(defface fixed-pitch
  `((t :font ,(font-spec :spacing 'M)))
  "The basic fixed-pitch face."
  :group 'basic-faces)

Made Emacs choose this font:

    ftcrhb:-GOOG-Noto Sans CJK KR-regular-normal-normal-*-45-*-*-*-*-0-iso10646-1 (#x24)

Which is not a monospace font (and is a different font family than the
`default' face uses:

    ftcrhb:-DAMA-Ubuntu Mono-regular-normal-normal-*-45-*-*-*-m-0-iso10646-1 (#x47)

So that seems to be another bug in this area?

I also tried this in Emacs 28 and earlier, and it does nothing there, so
it's broken in a different way on master than in Emacs 28.






^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-17 11:35                                 ` Lars Ingebrigtsen
@ 2022-10-17 12:58                                   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-10-17 14:26                                   ` Eli Zaretskii
  1 sibling, 0 replies; 29+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-17 12:58 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, 57962, stefankangas

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Maybe with "fixed-*" fonts this is so.  But isn't True Type fonts
>> scalable, so that we can request any size and get what we request?
>
> We can request "size 12", but how big that is varies greatly by font,
> unfortunately.  The font people haven't standarised this -- because of
> the origins of font tech, and that "optical size" can vary even with the
> same physical sizes.  So it's a mess, basically.
>
>> Is that because ":spacing 'm" doesn't work (it seems to work for me)?
>> If so, I think we should try fixing that instead of introducing new
>> wizardry.
>
> This:
>
> (defface fixed-pitch
>   `((t :font ,(font-spec :spacing 'M)))
>   "The basic fixed-pitch face."
>   :group 'basic-faces)
>
> Made Emacs choose this font:
>
>     ftcrhb:-GOOG-Noto Sans CJK KR-regular-normal-normal-*-45-*-*-*-*-0-iso10646-1 (#x24)
>
> Which is not a monospace font (and is a different font family than the
> `default' face uses:
>
>     ftcrhb:-DAMA-Ubuntu Mono-regular-normal-normal-*-45-*-*-*-m-0-iso10646-1 (#x47)
>
> So that seems to be another bug in this area?
>
> I also tried this in Emacs 28 and earlier, and it does nothing there, so
> it's broken in a different way on master than in Emacs 28.

I don't see that here, could you please try to bisect to the change that
causes the bug?

I suspect one of the changes to xfaces.c that happened a month or so
ago, so if bisecting isn't convenient for you just try reverting
xfaces.c to progressively earlier revisions and see where (and if) that
bug disappears.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-17  9:57                             ` Lars Ingebrigtsen
  2022-10-17 10:22                               ` Eli Zaretskii
@ 2022-10-17 14:20                               ` Stefan Kangas
  2022-10-17 14:34                                 ` Eli Zaretskii
  2022-10-18  0:38                                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 2 replies; 29+ messages in thread
From: Stefan Kangas @ 2022-10-17 14:20 UTC (permalink / raw)
  To: Lars Ingebrigtsen, Eli Zaretskii; +Cc: luangruo, 57962

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So there is no way to say "I have font X, give me font Y of the same
> size".

Right.  And in Emacs, this stuff tends to stick out more because we are
firmly in the uncanny valley between having the text rendering
capabilities of an average web browser (but we are much less advanced)
and a terminal emulator (but we are much more advanced).

> So I think we just have to mitigate this on a practical level, and the
> practical problem we have is that we expect a (fixed pitch) `default' font
> to have the same size as the `help-key-binding' font, since we mix these
> faces so much in our displays, and we want them to line up in tabular
> outputs.
>
> This means that we can either remove ":inherit fixed-pitch" from the
> latter face -- and that would fix the problem in 99.7% of the cases.
> But ideally, we'd like to have that face be fixed-pitch even if
> `default' uses a proportional font (which is possibly, but very very
> unusual).

Making `help-key-binding' just inherit from `default' is easy enough,
but we already expect that face to work even with `variable-pitch-mode':
see `help-for-help'.  :-(

So if don't have time to find a more proper solution for Emacs 29, we
would probably want to add some local hack there.  (We could make
`help-for-help' not use `variable-pitch-mode' too.  But that would be a
step backwards, IMHO, so I'd rather live with a hack.)

Maybe we should have `fixed-pitch' just always use the same font as the
default face?  If we want some other look in info (or wherever we
currently use it) we should perhaps add some other face we could inherit
from there.  But then, maybe figuring out how to do that is what this
entire thread is about...?

> To achieve that we'd have to implement something like
>
>   :inherit (if (monospacep 'default) 'default 'fixed-pitch)
>
> or something?

Something like that, or perhaps make it depend on `variable-pitch-mode'?





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-17 11:35                                 ` Lars Ingebrigtsen
  2022-10-17 12:58                                   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-10-17 14:26                                   ` Eli Zaretskii
  1 sibling, 0 replies; 29+ messages in thread
From: Eli Zaretskii @ 2022-10-17 14:26 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: luangruo, 57962, stefankangas

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: luangruo@yahoo.com,  57962@debbugs.gnu.org,  stefankangas@gmail.com
> Date: Mon, 17 Oct 2022 13:35:46 +0200
> 
> > Is that because ":spacing 'm" doesn't work (it seems to work for me)?
> > If so, I think we should try fixing that instead of introducing new
> > wizardry.
> 
> This:
> 
> (defface fixed-pitch
>   `((t :font ,(font-spec :spacing 'M)))
>   "The basic fixed-pitch face."
>   :group 'basic-faces)
> 
> Made Emacs choose this font:
> 
>     ftcrhb:-GOOG-Noto Sans CJK KR-regular-normal-normal-*-45-*-*-*-*-0-iso10646-1 (#x24)
> 
> Which is not a monospace font (and is a different font family than the
> `default' face uses:
> 
>     ftcrhb:-DAMA-Ubuntu Mono-regular-normal-normal-*-45-*-*-*-m-0-iso10646-1 (#x47)
> 
> So that seems to be another bug in this area?

Maybe this is because font_delete_unmatched doesn't pay attention to
:spacing?  Can you try adding that there, to see whether it could fix
this?

font_sort_entities and font_match_p also could be related, but I don't
know if they are called in this scenario.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-17 14:20                               ` Stefan Kangas
@ 2022-10-17 14:34                                 ` Eli Zaretskii
  2022-10-17 15:40                                   ` Stefan Kangas
  2022-10-18  0:38                                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 1 reply; 29+ messages in thread
From: Eli Zaretskii @ 2022-10-17 14:34 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: luangruo, larsi, 57962

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 17 Oct 2022 14:20:06 +0000
> Cc: luangruo@yahoo.com, 57962@debbugs.gnu.org
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > So there is no way to say "I have font X, give me font Y of the same
> > size".
> 
> Right.  And in Emacs, this stuff tends to stick out more because we are
> firmly in the uncanny valley between having the text rendering
> capabilities of an average web browser (but we are much less advanced)
> and a terminal emulator (but we are much more advanced).

I don't think this is accurate, let alone fair.

AFAIK, an average browser comes with a fixed system-dependent list of
fonts it uses for its various display parts, and doesn't allow users
any freedom in determining typefaces of various display parts, except
by replacing the fixed list of fonts by another fixed list.  There's
AFAIK nothing even close to Emacs's fontsets and faces.

So the job of an average browser is much easier, and the freedom of
its users is much smaller.  IOW, we are trying to solve a much harder
problem.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-17 14:34                                 ` Eli Zaretskii
@ 2022-10-17 15:40                                   ` Stefan Kangas
  0 siblings, 0 replies; 29+ messages in thread
From: Stefan Kangas @ 2022-10-17 15:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: luangruo, larsi, 57962

Eli Zaretskii <eliz@gnu.org> writes:

> AFAIK, an average browser comes with a fixed system-dependent list of
> fonts it uses for its various display parts, and doesn't allow users
> any freedom in determining typefaces of various display parts, except
> by replacing the fixed list of fonts by another fixed list.  There's
> AFAIK nothing even close to Emacs's fontsets and faces.
>
> So the job of an average browser is much easier, and the freedom of
> its users is much smaller.  IOW, we are trying to solve a much harder
> problem.

You can have arbitrary fonts in web browsers too, but it's true that
they are generally much less customizable (for the user) than Emacs.

They also usually don't have a block cursor to edit it all with, so they
get away with things that we might consider imperfections, such as
uneven line heights.

We might be veering off too far from the issue at hand though.
Sorry about that.





^ permalink raw reply	[flat|nested] 29+ messages in thread

* bug#57962: 29.0.50; Odd font choices
  2022-10-17 14:20                               ` Stefan Kangas
  2022-10-17 14:34                                 ` Eli Zaretskii
@ 2022-10-18  0:38                                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  1 sibling, 0 replies; 29+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-10-18  0:38 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Lars Ingebrigtsen, 57962, Eli Zaretskii

Stefan Kangas <stefankangas@gmail.com> writes:

> Right.  And in Emacs, this stuff tends to stick out more because we are
> firmly in the uncanny valley between having the text rendering
> capabilities of an average web browser (but we are much less advanced)
> and a terminal emulator (but we are much more advanced).

Arguably untrue, because I've seen Firefox fail to display some Arabic
text that Emacs does fine with.





^ permalink raw reply	[flat|nested] 29+ messages in thread

end of thread, other threads:[~2022-10-18  0:38 UTC | newest]

Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-20 22:16 bug#57962: 29.0.50; Odd font choices Lars Ingebrigtsen
2022-09-21  2:19 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-09-21 10:43   ` Lars Ingebrigtsen
2022-10-14 11:41     ` Lars Ingebrigtsen
2022-10-14 11:53       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-14 12:02         ` Lars Ingebrigtsen
2022-10-14 12:05           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-14 12:13             ` Lars Ingebrigtsen
2022-10-14 12:20               ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-14 12:07       ` Eli Zaretskii
2022-10-14 12:18         ` Lars Ingebrigtsen
2022-10-14 12:37           ` Eli Zaretskii
2022-10-14 12:48             ` Lars Ingebrigtsen
2022-10-14 13:00               ` Eli Zaretskii
2022-10-14 13:06                 ` Lars Ingebrigtsen
2022-10-14 13:09                   ` Eli Zaretskii
2022-10-16 10:58                     ` Lars Ingebrigtsen
2022-10-16 11:17                       ` Eli Zaretskii
2022-10-16 12:19                         ` Lars Ingebrigtsen
2022-10-16 13:53                           ` Eli Zaretskii
2022-10-17  9:57                             ` Lars Ingebrigtsen
2022-10-17 10:22                               ` Eli Zaretskii
2022-10-17 11:35                                 ` Lars Ingebrigtsen
2022-10-17 12:58                                   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-10-17 14:26                                   ` Eli Zaretskii
2022-10-17 14:20                               ` Stefan Kangas
2022-10-17 14:34                                 ` Eli Zaretskii
2022-10-17 15:40                                   ` Stefan Kangas
2022-10-18  0:38                                 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).