GNU bug report logs -
#19889
tex-verbatim face: don't specify :family?
Previous Next
Reported by: Glenn Morris <rgm <at> gnu.org>
Date: Tue, 17 Feb 2015 20:40:02 UTC
Severity: normal
Found in version 24.4
Done: Paul Eggert <eggert <at> cs.ucla.edu>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19889 in the body.
You can then email your comments to 19889 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Tue, 17 Feb 2015 20:40:02 GMT)
Full text and
rfc822 format available.
Message #3 received at submit <at> debbugs.gnu.org (full text, mbox):
Package: emacs
Version: 24.4
Severity: minor
The tex-verbatim face is defined as
'((t :family "courier"))
Is this a good idea?
AFAICS, it is the only face definition in Emacs that specifies a :family.
It seems to cause problems on some systems, see:
https://bugzilla.redhat.com/show_bug.cgi?id=684797
For me on RHEL7, that faces looks poor (blocky/pixellated) compared to
the other faces Emacs uses.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Wed, 18 Feb 2015 03:45:02 GMT)
Full text and
rfc822 format available.
Message #6 received at 19889 <at> debbugs.gnu.org (full text, mbox):
> The tex-verbatim face is defined as
> '((t :family "courier"))
> Is this a good idea?
I think/thought so.
> AFAICS, it is the only face definition in Emacs that specifies a :family.
There's also
(defface Info-quoted
'((t :family "courier"))
"Face used for quoted elements.")
> It seems to cause problems on some systems, see:
> https://bugzilla.redhat.com/show_bug.cgi?id=684797
> For me on RHEL7, that faces looks poor (blocky/pixellated) compared to
> the other faces Emacs uses.
Maybe we should improve face-font-family-alternatives so as to
automatically find a better courier-like font?
Maybe we also should define a standard/core face for this, which is then
inherited by both tex-verbatim and Info-quoted.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Wed, 18 Feb 2015 07:41:01 GMT)
Full text and
rfc822 format available.
Message #9 received at 19889 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier wrote:
> There's also
>
> (defface Info-quoted
> '((t :family "courier"))
> "Face used for quoted elements.")
I see that's relatively new, and only in master.
> Maybe we should improve face-font-family-alternatives so as to
> automatically find a better courier-like font?
>
> Maybe we also should define a standard/core face for this, which is then
> inherited by both tex-verbatim and Info-quoted.
Maybe.
FWIW tex-verbatim looks ok on Debian testing, but as I said not so good
on RHEL7.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Wed, 18 Feb 2015 14:37:02 GMT)
Full text and
rfc822 format available.
Message #12 received at 19889 <at> debbugs.gnu.org (full text, mbox):
> FWIW tex-verbatim looks ok on Debian testing, but as I said not so good
> on RHEL7.
I did see that, and as I said, this should be fixed by adding an
appropriate replacement to face-font-family-alternatives.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Wed, 18 Feb 2015 19:15:04 GMT)
Full text and
rfc822 format available.
Message #15 received at 19889 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
C-u C-x = tells me that the font Emacs picks for tex-verbatim is
x:-adobe-courier-medium-r-normal--14-140-75-75-m-90-USO8859-1 (#x6D)
So presumably the problem is that it picks an x font rather than an xft one.
See attached image for how it looks clunky in info.
(I don't normally use Emacs trunk or makeinfo 5, so haven't noticed this
before.)
Firefox just uses "Monospace" font.
Gnome-terminal has "use the system fixed-with font".
IIUC, fc-match tells me that monspace == DejaVu Sans Mono.
I know little about fonts, but it seems suboptimal to me to try and
specify a family for a handful of faces, since it's impossible to
predict how it will look in conjunction with the user's other fonts.
[a.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Wed, 18 Feb 2015 20:53:01 GMT)
Full text and
rfc822 format available.
Message #18 received at submit <at> debbugs.gnu.org (full text, mbox):
Glenn Morris <rgm <at> gnu.org> writes:
> Package: emacs
> Version: 24.4
> Severity: minor
>
> The tex-verbatim face is defined as
>
> '((t :family "courier"))
>
> Is this a good idea?
>
> AFAICS, it is the only face definition in Emacs that specifies a :family.
Info-quoted also does this.
Looking at `grep -iIR ':family "cou' *`, it looks like those are the
only two.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Wed, 18 Feb 2015 20:54:02 GMT)
Full text and
rfc822 format available.
Message #21 received at submit <at> debbugs.gnu.org (full text, mbox):
On 18/02/15 at 03:51pm, Mark Oteiza wrote:
> Glenn Morris <rgm <at> gnu.org> writes:
> > AFAICS, it is the only face definition in Emacs that specifies a :family.
>
> Info-quoted also does this.
>
> Looking at `grep -iIR ':family "cou' *`, it looks like those are the
> only two.
I should have read ahead, sorry.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Thu, 19 Feb 2015 01:56:02 GMT)
Full text and
rfc822 format available.
Message #24 received at 19889 <at> debbugs.gnu.org (full text, mbox):
> So presumably the problem is that it picks an x font rather than an xft one.
> See attached image for how it looks clunky in info.
Yes, that's the usual cause for blocky fonts.
> Firefox just uses "Monospace" font.
When/where?
> Gnome-terminal has "use the system fixed-with font".
How's that relevant for tex-verbatim or Info-quoted?
> IIUC, fc-match tells me that monspace == DejaVu Sans Mono.
For tex-verbatim, it shouldn't just be monospaced, but should look
somewhat like TeX's verbatim font (i.e. old typewriter style, i.e. courier).
For Info-quoted, it's not indispensable that it looks like courier, but
it should look different from the default font (by default). IIUC the
default font nowadays is a monospaced sans-serif font, so I chose
a monospaced font with serif.
> I know little about fonts, but it seems suboptimal to me to try and
> specify a family for a handful of faces, since it's impossible to
> predict how it will look in conjunction with the user's other fonts.
I think we should define a `fixed-width-with-serif' face and inherit
from that, to make the intention clear.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Thu, 19 Feb 2015 02:22:01 GMT)
Full text and
rfc822 format available.
Message #27 received at 19889 <at> debbugs.gnu.org (full text, mbox):
Stefan Monnier wrote:
>> Firefox just uses "Monospace" font.
>
> When/where?
edit/prefs/content/advanced
>> Gnome-terminal has "use the system fixed-with font".
>
> How's that relevant for tex-verbatim or Info-quoted?
"Person who know nothing about fonts tries to provide potentially
relevant information from other applications where the fonts look better
than the one Emacs picked." :)
Forcibly Merged 19889 22207.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Fri, 18 Dec 2015 19:00:02 GMT)
Full text and
rfc822 format available.
Added indication that bug 19889 blocks19759
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Fri, 18 Dec 2015 19:00:03 GMT)
Full text and
rfc822 format available.
Disconnected #19889 from all other report(s).
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Thu, 05 May 2016 21:01:02 GMT)
Full text and
rfc822 format available.
Did not alter fixed versions and reopened.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 05 May 2016 21:01:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Thu, 05 May 2016 22:55:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 19889 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[Redirecting from Bug#22207]
On 05/05/2016 02:29 PM, Glenn Morris wrote:
> Info-quoted and tex-verbatim faces
> continue to look poor on RHEL 7, so I unmerged and reopened my own
> #19889.
>
Please try the attached patch against Emacs 25. It attempts to implement
Stefan's suggestions in Bug#19889, and this improved things for me on
Fedora 23, when I ran 'emacs -Q'.
Although this patch makes things worse when I run emacs without -Q, that
is because I have this in my ~/.Xresources:
Emacs.font: -misc-fixed-medium-r-semicondensed--0-0-75-75-c-0-iso8859-1
which is an old-timer expert setting that I should really fix one of
these days, so I wouldn't put too much weight on my glitch.
[0001-Improve-display-of-tex-verbatim.patch (application/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Fri, 06 May 2016 06:38:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 19889 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Date: Thu, 05 May 2016 17:29:20 -0400
> Cc: eggert <at> cs.ucla.edu
>
> Paul Eggert wrote:
>
> > I just now attempted to reproduce this bug on emacs-25, and could not
> > reproduce it; the display looks OK (see attached). Although I am still
> > running Fedora 23 x86-64, I have installed several packages since the
> > original bug report in December so it's possible that the problem has
> > gone away because some new fonts have been installed. Another
> > possibility is that the bug has been fixed in draft Emacs 25 somehow.
> > Either way, I will close this particular bug report now as I can't
> > reproduce it.
>
> Nothing's changed in Emacs, and Info-quoted and tex-verbatim faces
> continue to look poor on RHEL 7, so I unmerged and reopened my own
> #19889.
Is what you see similar to what's shown on the image attached to
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19889#15? If so, can you
explain what is your problem with that display? It looks fine to me,
but maybe I'm missing something.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Fri, 06 May 2016 06:50:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 19889 <at> debbugs.gnu.org (full text, mbox):
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Thu, 5 May 2016 15:54:39 -0700
>
> On 05/05/2016 02:29 PM, Glenn Morris wrote:
> > Info-quoted and tex-verbatim faces
> > continue to look poor on RHEL 7, so I unmerged and reopened my own
> > #19889.
> >
> Please try the attached patch against Emacs 25. It attempts to implement
> Stefan's suggestions in Bug#19889, and this improved things for me on
> Fedora 23, when I ran 'emacs -Q'.
>
> Although this patch makes things worse when I run emacs without -Q, that
> is because I have this in my ~/.Xresources:
>
> Emacs.font: -misc-fixed-medium-r-semicondensed--0-0-75-75-c-0-iso8859-1
>
> which is an old-timer expert setting that I should really fix one of
> these days, so I wouldn't put too much weight on my glitch.
If we are going to use such kludges, why not specify fonts explicitly
in the defface to begin with? After all, that's what your patch
attempts to do, albeit indirectly, right?
In general, I find the family specification to be too fragile for any
reliable specification of typefaces: the results are inconsistent
across different systems and tend to depend too much on local setup.
Unfortunately, we don't have a font expert on board who could point
out how to do that better, or how to improve the current font
selection machinery to produce more reliable results. (My impression
is that all the font-related attributes are not perceived as mandatory
enough, and the font selection code tries very hard to find _some_
font, even if it doesn't fit the constraints. But I have no proof for
this impression.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Fri, 06 May 2016 15:49:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 19889 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> In general, I find the family specification to be too fragile for any
> reliable specification of typefaces: the results are inconsistent
> across different systems and tend to depend too much on local setup.
That was exactly the point of my report.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Fri, 06 May 2016 15:59:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 19889 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 19889 <at> debbugs.gnu.org
> Date: Fri, 06 May 2016 11:47:58 -0400
>
> Eli Zaretskii wrote:
>
> > In general, I find the family specification to be too fragile for any
> > reliable specification of typefaces: the results are inconsistent
> > across different systems and tend to depend too much on local setup.
>
> That was exactly the point of my report.
OK, but you seemed also to complain about the results in your
particular case, which (according to the image you posted) I find
satisfactory: we asked for a monospaced font and got a monospaced
font, which looks different from the default one. So if there's any
problem with that image, can you point it out?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Fri, 06 May 2016 16:01:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 19889 <at> debbugs.gnu.org (full text, mbox):
On 05/05/2016 11:49 PM, Eli Zaretskii wrote:
> If we are going to use such kludges, why not specify fonts explicitly
> in the defface to begin with? After all, that's what your patch
> attempts to do, albeit indirectly, right?
The patch I proposed basically implements the suggestions Stefan made in
<http://bugs.gnu.org/19889#6> and <http://bugs.gnu.org/19889#24>. Stefan
was responding to Glenn’s original bug report, which suggests that it is
not a good idea for a face definition to specify a font explicitly, due
to portability problems on systems lacking the font. See the attachment
to <https://bugzilla.redhat.com/684797> for an example of how verbatim
text in TeX mode was displayed as little black boxes because TeX mode
specifies an explicit font on a platform lacking it.
I am by no means an expert on Emacs fonts or on font technology in
general. That being said, I would like to fix this blocking bug, and
Stefan’s suggestion was the only concrete one on the table. If the patch
is problematic, then is there a better way to fix this bug? More
specifically: is it the introduction of ‘fixed-pitch-serif’ that you’re
objecting to, or the addition of FreeMono and Nimbus Mono L as fonts to
look for, or is it something else? Is there some way we could make the
patch less kludgy, while still addressing Glenn’s and Stefan’s concerns?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Fri, 06 May 2016 16:03:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 19889 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> Is what you see similar to what's shown on the image attached to
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19889#15? If so, can you
> explain what is your problem with that display?
That face looks poor compared to all the others.
If you don't agree with me, fine, please just close this as wontfix,
since I've said everything I can possibly say on this subject already
and it doesn't seem to bother others.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Fri, 06 May 2016 16:25:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 19889 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 05/06/2016 08:58 AM, Eli Zaretskii wrote:
> if there's any
> problem with that image, can you point it out?
Here is my reaction to Glenn’s attachment to
<http://bugs.gnu.org/19889#15>. Some users are reaaaaally annoyed by
aliased (“jagged”) fonts, particularly when combined with text that is
mostly anti-aliased. The annoyance level can depend on the display
technology: due to subpixel rendering, for example, what you see when
you look at Glenn’s attachment on your display may differ from what
Glenn sees on his display.
Other users aren’t bothered at all.
With all this in mind, I can sympathize with Glenn’s discomfort with his
attachment: although on my display it is sort of OK (certainly better
than I observed in my attachment to <http://bugs.gnu.org/22207#1>), the
serifed text is distractingly blocky.
Plus, there’s another problem with Emacs’s current approach: on my
Fedora 23 platform, the jagged font lacks serifs, which defeats the main
point of specifying Courier for quoted Info text.
The combination of these two issues makes the Emacs manual look more
amateurish on my platform. In contrast, the anti-aliased font is
smoother and fits in better. Although many users will not care about the
difference, some will. I’ll attach screenshots to try to illustrate.
Although I think this bug should be fixed, the patch’s improvement is
small enough that I do not see the bug as a blocker against Emacs 25.
[without-patch.png (image/png, attachment)]
[with-patch.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Fri, 06 May 2016 17:17:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 19889 <at> debbugs.gnu.org (full text, mbox):
> Cc: 19889 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Fri, 6 May 2016 09:24:11 -0700
>
> Here is my reaction to Glenn’s attachment to
> <http://bugs.gnu.org/19889#15>. Some users are reaaaaally annoyed by
> aliased (“jagged”) fonts, particularly when combined with text that is
> mostly anti-aliased. The annoyance level can depend on the display
> technology: due to subpixel rendering, for example, what you see when
> you look at Glenn’s attachment on your display may differ from what
> Glenn sees on his display.
>
> Other users aren’t bothered at all.
I guess I belong to the latter group. I see the difference, but I'm
not bothered by it. What matters is that the font should be
monospaced; beyond that, we have very little to expect.
> Plus, there’s another problem with Emacs’s current approach: on my
> Fedora 23 platform, the jagged font lacks serifs, which defeats the main
> point of specifying Courier for quoted Info text.
AFAIU, the main point of specifying that face was to have a face
different from default that is still monospaced. And both fonts
satisfy that condition, so I don't see any further problems we should
care about.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Fri, 06 May 2016 17:19:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 19889 <at> debbugs.gnu.org (full text, mbox):
> Cc: rgm <at> gnu.org, 19889 <at> debbugs.gnu.org,
> Stefan Monnier <monnier <at> IRO.UMontreal.CA>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Fri, 6 May 2016 08:59:48 -0700
>
> I am by no means an expert on Emacs fonts or on font technology in
> general. That being said, I would like to fix this blocking bug, and
> Stefan’s suggestion was the only concrete one on the table. If the patch
> is problematic, then is there a better way to fix this bug?
We could specify the font explicitly.
> More specifically: is it the introduction of ‘fixed-pitch-serif’
> that you’re objecting to, or the addition of FreeMono and Nimbus
> Mono L as fonts to look for
The latter. I see that as a (perhaps complicated and a bit
unreliable) way of specifying a font which we know we want to get as
result. If so, why not specify the font explicitly?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Fri, 06 May 2016 18:25:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 19889 <at> debbugs.gnu.org (full text, mbox):
On 05/06/2016 10:18 AM, Eli Zaretskii wrote:
> We could specify the font explicitly.
>
>> >More specifically: is it the introduction of ‘fixed-pitch-serif’
>> >that you’re objecting to, or the addition of FreeMono and Nimbus
>> >Mono L as fonts to look for
> The latter. I see that as a (perhaps complicated and a bit
> unreliable) way of specifying a font which we know we want to get as
> result. If so, why not specify the font explicitly?
The problem is, which font to specify explicitly? Not all platforms have
a font named "Courier". Mine doesn't (Fedora 23). If we knew that all
Emacs platforms had an appropriate font (Courier, or FreeMono, or Nimbus
Mono L, or whatever), we could specify that font, but I do not know of
any such font, nor do I know how to query arbitrary platforms for such a
font.
In further testing on my Fedora 23 host I discovered another suitable
anti-aliased font, Courier 10 Pitch. It is also a free font and looks a
bit better with emacs -Q, and Wikipedia says Courier 10 Pitch BT is the
default Courier font on many GNU/Linux hosts
<https://en.wikipedia.org/wiki/Courier_%28typeface%29#Courier_10_Pitch_BT>.
So I will update my proposed patch to prefer Courier 10 Pitch to the
alternatives already in the list.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Fri, 06 May 2016 19:03:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 19889 <at> debbugs.gnu.org (full text, mbox):
> Cc: rgm <at> gnu.org, 19889 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Fri, 6 May 2016 11:24:14 -0700
>
> On 05/06/2016 10:18 AM, Eli Zaretskii wrote:
> > We could specify the font explicitly.
> >
> >> >More specifically: is it the introduction of ‘fixed-pitch-serif’
> >> >that you’re objecting to, or the addition of FreeMono and Nimbus
> >> >Mono L as fonts to look for
> > The latter. I see that as a (perhaps complicated and a bit
> > unreliable) way of specifying a font which we know we want to get as
> > result. If so, why not specify the font explicitly?
>
> The problem is, which font to specify explicitly? Not all platforms have
> a font named "Courier". Mine doesn't (Fedora 23). If we knew that all
> Emacs platforms had an appropriate font (Courier, or FreeMono, or Nimbus
> Mono L, or whatever), we could specify that font, but I do not know of
> any such font, nor do I know how to query arbitrary platforms for such a
> font.
I'm aware of the issue, but I very much doubt there are too many
variants out there. We could enumerate them all, and try one after
another, or even do it specifically for each platform. Which is more
or less what your patch does, isn't it?
> In further testing on my Fedora 23 host I discovered another suitable
> anti-aliased font, Courier 10 Pitch.
So why do you say above you don't have Courier?
> It is also a free font and looks a bit better with emacs -Q, and
> Wikipedia says Courier 10 Pitch BT is the default Courier font on
> many GNU/Linux hosts
> <https://en.wikipedia.org/wiki/Courier_%28typeface%29#Courier_10_Pitch_BT>.
> So I will update my proposed patch to prefer Courier 10 Pitch to the
> alternatives already in the list.
We could systematically review the most popular platforms (how many
are there, anyway?), and simply state a font or a couple of them for
each platform. And I won't be surprised if all of them mostly use the
same fonts, even if some of them aren't necessarily present sometimes.
IOW, I prefer naming fonts rather than asking for them via families.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Fri, 06 May 2016 19:33:01 GMT)
Full text and
rfc822 format available.
Message #74 received at 19889 <at> debbugs.gnu.org (full text, mbox):
> The problem is, which font to specify explicitly? Not all platforms
> have a font named "Courier".
That's what face-font-family-alternatives is for. We already have an
entry in there for "courier", so it just needs to be completed.
Stefan
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Fri, 06 May 2016 20:10:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 19889 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
> Please try the attached patch against Emacs 25. It attempts to
> implement Stefan's suggestions in Bug#19889, and this improved things
> for me on Fedora 23, when I ran 'emacs -Q'.
Thanks, but it makes no difference for me on RHEL7.
Emacs still uses the same poor non-xft font:
x:-adobe-courier-medium-r-normal--14-140-75-75-m-90-iso8859-1
(The addition of fixed-pitch-serif as a base face is of course desirable.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Fri, 06 May 2016 20:24:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 19889 <at> debbugs.gnu.org (full text, mbox):
PS Manually setting the font family to "Nimbus Mono L" works.
This is what fc-match returns for me:
fc-match courier
n022003l.pfb: "Nimbus Mono L" "Regular"
Yet for "font family: courier", Emacs selects x:-adobe-courier-medium,
for some reason.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Sat, 07 May 2016 03:04:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 19889 <at> debbugs.gnu.org (full text, mbox):
On 05/06/2016 12:01 PM, Eli Zaretskii wrote:
> I very much doubt there are too many
> variants out there. We could enumerate them all, and try one after
> another, or even do it specifically for each platform. Which is more
> or less what your patch does, isn't it?
Yes, that's why I want to install the patch. :-)
>> In further testing on my Fedora 23 host I discovered another suitable
>> anti-aliased font, Courier 10 Pitch.
> So why do you say above you don't have Courier?
Because I don't have it exactly. The font on Fedora 23 is called "Courier 10
Pitch", not "Courier". It's from Bitstream and is quite close but not identical
to honest-to-goodness IBM Courier.
I just now checked another desktop, running Ubuntu 16.04, and it has the same
set of suitable fonts as Fedora 23. (It also has a Thai font that would suffice
for ASCII but this is probably not a good choice in general.)
> We could systematically review the most popular platforms (how many
> are there, anyway?), and simply state a font or a couple of them for
> each platform. And I won't be surprised if all of them mostly use the
> same fonts, even if some of them aren't necessarily present sometimes.
>
> IOW, I prefer naming fonts rather than asking for them via families.
The problem with Courier is that there are so many fonts that are all so similar
to Courier and most people can't tell the difference. This is partly due to the
intellectual history behind Courier.
I looked for a good source about this issue, and found someone who took a
circa-2012 census of Courier-like fonts on various web browsers and who
evaluated their looks when combined with non-Courier fonts. He writes that on
GNU/Linux platforms, the most common Courier fonts were Nimbus Mono L (98.2%)
and FreeMono (85.2%) but these fonts are a bit faint to be mixing with other
fonts, and that Courier 10 Pitch (85.0%) was a better choice. On OS X, he writes
that Courier Std (2.1%), Consolas (48.6%), and Courier (99.5%) are all good
choices, whereas Courier New (96.8%) is a bit faint. On MS-Windows, he says
Consolas (88.6%) and Courier (3.6%) are good choices, whereas FreeMono (0.6%)
and Courier New (99.8%) are a bit faint. As a result of all this, he suggests
the following order for Web use: "Courier 10 Pitch", "Courier Std", Consolas,
Courier, "TeX Gyre Cursor", TeXGyreCursor, "Nimbus Mono L", FreeMono,
"Courier New", monospace. See
<http://www.grputland.com/2012/08/font-stacks-that-look-similar-in.html#cour20120806>.
I doubt whether GNU Emacs should be defaulting to the non-free fonts in that
list(e.g., Consolas), given that the free fonts are so widely available.Courier
New is often disliked (it was digitized directly from the IBM Selectric golfball
which was at odds with how the Selectric actually worked). I don't know about
TeX Gyre Cursor, but it doesn't seem to be common on Fedora and Ubuntu anyway.
The other Courier-like fonts are close to the list I already proposed.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Sat, 07 May 2016 06:51:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 19889 <at> debbugs.gnu.org (full text, mbox):
> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, rgm <at> gnu.org, 19889 <at> debbugs.gnu.org
> Date: Fri, 06 May 2016 15:32:43 -0400
>
> > The problem is, which font to specify explicitly? Not all platforms
> > have a font named "Courier".
>
> That's what face-font-family-alternatives is for. We already have an
> entry in there for "courier", so it just needs to be completed.
But if what we want is a specific font, then adding its family will
produce unreliable results, and might well yield a font we don't want
in some setups.
IOW, what you suggest was already tried, and found to fail in some
cases. We are trying to fix those cases, so using the same technique
we already know is faulty sounds unwise to me.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Sat, 07 May 2016 06:54:02 GMT)
Full text and
rfc822 format available.
Message #89 received at 19889 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Date: Fri, 06 May 2016 16:22:53 -0400
> Cc: 19889 <at> debbugs.gnu.org
>
> PS Manually setting the font family to "Nimbus Mono L" works.
> This is what fc-match returns for me:
>
> fc-match courier
> n022003l.pfb: "Nimbus Mono L" "Regular"
>
> Yet for "font family: courier", Emacs selects x:-adobe-courier-medium,
> for some reason.
Both belong to the Courier family, right? So which one is found first
is entirely implementation-dependent.
When we ask for a family, we are saying that we will accept _any_
member of that family. If we are unwilling to accept some of its
members, we should request a specific font (or maybe specify more than
just a family, but I'm not aware of any such additional specs;
foundry, perhaps?).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Sat, 07 May 2016 07:02:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 19889 <at> debbugs.gnu.org (full text, mbox):
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Cc: rgm <at> gnu.org, 19889 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
> Date: Fri, 6 May 2016 20:03:09 -0700
>
> I looked for a good source about this issue, and found someone who took a
> circa-2012 census of Courier-like fonts on various web browsers and who
> evaluated their looks when combined with non-Courier fonts. He writes that on
> GNU/Linux platforms, the most common Courier fonts were Nimbus Mono L (98.2%)
> and FreeMono (85.2%) but these fonts are a bit faint to be mixing with other
> fonts, and that Courier 10 Pitch (85.0%) was a better choice. On OS X, he writes
> that Courier Std (2.1%), Consolas (48.6%), and Courier (99.5%) are all good
> choices, whereas Courier New (96.8%) is a bit faint. On MS-Windows, he says
> Consolas (88.6%) and Courier (3.6%) are good choices, whereas FreeMono (0.6%)
> and Courier New (99.8%) are a bit faint. As a result of all this, he suggests
> the following order for Web use: "Courier 10 Pitch", "Courier Std", Consolas,
> Courier, "TeX Gyre Cursor", TeXGyreCursor, "Nimbus Mono L", FreeMono,
> "Courier New", monospace. See
> <http://www.grputland.com/2012/08/font-stacks-that-look-similar-in.html#cour20120806>.
>
> I doubt whether GNU Emacs should be defaulting to the non-free fonts in that
> list(e.g., Consolas), given that the free fonts are so widely available.Courier
> New is often disliked (it was digitized directly from the IBM Selectric golfball
> which was at odds with how the Selectric actually worked). I don't know about
> TeX Gyre Cursor, but it doesn't seem to be common on Fedora and Ubuntu anyway.
> The other Courier-like fonts are close to the list I already proposed.
Courier New is the default font on MS-Windows, so selecting it means
we will have a face that is indistinguishable from the default: not
good.
Consolas comes with latest Windows versions out of the box, so I don't
think there's a problem in having it on the list (we could do that
only on Windows, if we don't want to recommend it on GNU/Linux).
I don't understand what "monospace" means in that list. There's no
such font, AFAIK, and all the other fonts are monospaced already, so
what's behind that "monospace"? any other monospaced font?
Other than that, how about using the outcome of that census, and
request specific fonts it mentions, ordered by their quality, as the
census recommends? I think this will yield better results than
relying on family matches.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Sat, 07 May 2016 16:57:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 19889 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Glenn Morris wrote:
> Thanks, but it makes no difference for me on RHEL7.
> Emacs still uses the same poor non-xft font:
>
> x:-adobe-courier-medium-r-normal--14-140-75-75-m-90-iso8859-1
>
> (The addition of fixed-pitch-serif as a base face is of course desirable.)
Thanks for checking. I reproduced your problem on Ubuntu 16.04 by installing the
optional package xfonts-75dpi. Please try the attached patch to emacs-25 instead
of what I sent earlier. This patch tries to address Eli's comments, which I'll
follow up on separately.
[0001-Improve-display-of-tex-verbatim-and-Info-quoted.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Sat, 07 May 2016 17:06:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 19889 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> Courier New is the default font on MS-Windows, so selecting it means
> we will have a face that is indistinguishable from the default: not
> good.
OK, the patch I just sent to Bug#19889 does that.
> Consolas comes with latest Windows versions out of the box, so I don't
> think there's a problem in having it on the list (we could do that
> only on Windows, if we don't want to recommend it on GNU/Linux).
Probably not worth the hassle. I merely listed it after Courier 10 Pitch.
> I don't understand what "monospace" means in that list. There's no
> such font, AFAIK, and all the other fonts are monospaced already, so
> what's behind that "monospace"? any other monospaced font?
The source was talking about CSS, and I guess "monospace" has a meaning in CSS
that is roughly the same as "Monospace" in face-font-family-alternatives.
> Other than that, how about using the outcome of that census, and
> request specific fonts it mentions, ordered by their quality, as the
> census recommends? I think this will yield better results than
> relying on family matches.
The patch I just sent does that, by inventing a name "Monospace Serif" as a way
to make the request conveniently as an argument to :family when using defface.
It sounds like you may prefer doing this sort of thing in some other way, but I
do not know what that way would be and so would appreciate any advice, as I am
by no means an expert in Emacs font configuration and am just trying to get the
bug fixed for the typical user.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Sat, 07 May 2016 17:28:01 GMT)
Full text and
rfc822 format available.
Message #101 received at 19889 <at> debbugs.gnu.org (full text, mbox):
> Cc: rgm <at> gnu.org, 19889 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 7 May 2016 10:05:27 -0700
>
> > Other than that, how about using the outcome of that census, and
> > request specific fonts it mentions, ordered by their quality, as the
> > census recommends? I think this will yield better results than
> > relying on family matches.
>
> The patch I just sent does that, by inventing a name "Monospace Serif" as a way
> to make the request conveniently as an argument to :family when using defface.
> It sounds like you may prefer doing this sort of thing in some other way
No, what your patch does is fine with me, actually. It does call out
font names, which is what I had in mind.
The result on my system is to use Consolas where Emacs previously used
Courier, to display symbols in Info buffers. I don't mind the change,
but I'd urge others to try the patch and see if it causes any
problems.
> I am by no means an expert in Emacs font configuration
No one is these days, unfortunately.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Sat, 07 May 2016 20:38:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 19889 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> I don't mind the change,
> but I'd urge others to try the patch and see if it causes any
> problems.
Yes, it's Glenn in particular that I had in mind. If this patch works for Glenn
I'm inclined to install it into the emacs-25 branch (which will encourage others
to test it too...).
Reply sent
to
Paul Eggert <eggert <at> cs.ucla.edu>:
You have taken responsibility.
(Fri, 13 May 2016 21:34:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Glenn Morris <rgm <at> gnu.org>:
bug acknowledged by developer.
(Fri, 13 May 2016 21:34:01 GMT)
Full text and
rfc822 format available.
Message #109 received at 19889-done <at> debbugs.gnu.org (full text, mbox):
On 05/07/2016 10:27 AM, Eli Zaretskii wrote:
> I don't mind the change,
> but I'd urge others to try the patch and see if it causes any
> problems.
I installed the patch into master, to get the ball rolling on that.
Although I had been thinking of installing the patch into emacs-25, I
see that Bug#19759 no longer lists 19889 or 22207 as blockers, which
means emacs-25 is not a suitable place for the patch. (Bug#22207 was a
blocker but I could not reproduce it and so closed it on May 5.)
Bug#19889 says it blocks 19759 as of 2015-12-18 and there is no
indication it was ever unblocked. Conversely, Bug#19759 does not
currently list Bug#19889 as a blocker; I don't know why not. If
Bug#19889 is supposed to still be a blocker, then the patch should be
backported from master to emacs-25.
At any event Bug#19889 seems to be fixed in master, so I am boldly
closing it now; if this is wrong we can always reopen it of course.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Sat, 14 May 2016 07:49:01 GMT)
Full text and
rfc822 format available.
Message #112 received at 19889 <at> debbugs.gnu.org (full text, mbox):
> Cc: rgm <at> gnu.org, 19889-done <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Fri, 13 May 2016 14:33:17 -0700
>
> Bug#19889 says it blocks 19759 as of 2015-12-18 and there is no
> indication it was ever unblocked. Conversely, Bug#19759 does not
> currently list Bug#19889 as a blocker; I don't know why not.
Perhaps this happened when 19889 was unmerged from all the other bug
reports.
I don't know if it should be a blocker: does the problem still exist
on emacs-25, and if so, is it bad enough to block the release?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Sat, 14 May 2016 08:25:02 GMT)
Full text and
rfc822 format available.
Message #115 received at 19889 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> does the problem still exist
> on emacs-25,
Yes.
> is it bad enough to block the release?
Not from what I can see. On my screen it's a relatively minor issue (i.e., an
ugly font, but still readable).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#19889; Package
emacs.
(Sat, 14 May 2016 09:29:01 GMT)
Full text and
rfc822 format available.
Message #118 received at 19889 <at> debbugs.gnu.org (full text, mbox):
> Cc: rgm <at> gnu.org, 19889 <at> debbugs.gnu.org, monnier <at> IRO.UMontreal.CA
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Sat, 14 May 2016 01:24:11 -0700
>
> Eli Zaretskii wrote:
> > does the problem still exist
> > on emacs-25,
>
> Yes.
>
> > is it bad enough to block the release?
>
> Not from what I can see. On my screen it's a relatively minor issue (i.e., an
> ugly font, but still readable).
Then I think we can leave the fix on master. (I tried on my system,
and the font is also readable, and not even ugly IMO -- but it's a
different font from what you see, of course.)
Thanks.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 11 Jun 2016 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 7 years and 312 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.