bug#19889: tex-verbatim face: don't specify :family?

bug#19889: tex-verbatim face: don't specify :family?

[Glenn Morris]

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.

bug#19889: tex-verbatim face: don't specify :family?

[Stefan Monnier]

> 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

bug#19889: tex-verbatim face: don't specify :family?

[Glenn Morris]

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.

bug#19889: tex-verbatim face: don't specify :family?

[Stefan Monnier]

> 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

bug#19889: tex-verbatim face: don't specify :family?

[Glenn Morris]

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


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.


[-- Attachment #2: a.png --]
[-- Type: image/png, Size: 48171 bytes --]

bug#19889: tex-verbatim face: don't specify :family?

[Stefan Monnier]

> 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

bug#19889: tex-verbatim face: don't specify :family?

[Glenn Morris]

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." :)

bug#19889: tex-verbatim face: don't specify :family?

[Mark Oteiza]

Glenn Morris <rgm@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.

bug#19889: tex-verbatim face: don't specify :family?

[Mark Oteiza]

On 18/02/15 at 03:51pm, Mark Oteiza wrote:
> Glenn Morris <rgm@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.

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Paul Eggert]

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

When I use emacs-25 to view the Elisp manual on Fedora 23 x86-64, Emacs 
mishandles the font for code: code is displayed in a considerably 
smaller font, making the manual harder to read and looking a bit like a 
ransom note. A sample is attached. I am using 'emacs -Q' to read the 
info file. If I view the same (i.e., the emacs-25) info file with Emacs 
24.5 as bundled with Fedora, the display looks fine, with the same 
fixed-width font used for all text.


In GNU Emacs 25.0.50.8 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.6)
  of 2015-12-17
Repository revision: 1b5630eb47d3f4bade09708c958ab006b83b3fc0
Windowing system distributor 'Fedora Project', version 11.0.11800000
Configured using:
  'configure --enable-gcc-warnings'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
   value of $LANG: en_US.UTF-8
   value of $XMODIFIERS: @im=ibus
   locale-coding-system: utf-8-unix

Major mode: Info

Minor modes in effect:
   shell-dirtrack-mode: t
   tooltip-mode: t
   global-eldoc-mode: t
   electric-indent-mode: t
   mouse-wheel-mode: t
   tool-bar-mode: t
   menu-bar-mode: t
   file-name-shadow-mode: t
   global-font-lock-mode: t
   font-lock-mode: t
   blink-cursor-mode: t
   auto-composition-mode: t
   auto-encryption-mode: t
   auto-compression-mode: t
   buffer-read-only: t
   line-number-mode: t
   transient-mark-mode: t

Recent messages:
Checking 24 files in /home/eggert/src/gnu/emacs/my/lisp/cedet...
Checking 57 files in /home/eggert/src/gnu/emacs/my/lisp/calendar...
Checking 87 files in /home/eggert/src/gnu/emacs/my/lisp/calc...
Checking 122 files in /home/eggert/src/gnu/emacs/my/lisp/obsolete...
Checking for load-path shadows...done
You can run the command ‘report-emacs-bug’ with M-x r-em RET
Checking for load-path shadows...done
Auto-saving...done
Quit [3 times]
C-M-g is undefined

Load-path shadows:
None found.

Features:
(pp shadow sort gnus-util mail-extr emacsbug message dired format-spec
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils help-fns help-mode cl-loaddefs pcase
cl-lib shell pcomplete comint ansi-color ring info easymenu time-date
mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset
image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 123742 15169)
  (symbols 48 19951 3)
  (miscs 40 89 292)
  (strings 32 23330 7050)
  (string-bytes 1 657185)
  (vectors 16 12693)
  (vector-slots 8 432940 13272)
  (floats 8 150 162)
  (intervals 56 4895 83)
  (buffers 976 16)
  (heap 1024 38893 944))


[-- Attachment #2: Screenshot from 2015-12-18 10-21-19.png --]
[-- Type: image/png, Size: 15715 bytes --]

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Paul Eggert]

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

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.


[-- Attachment #2: Screenshot-from-2016-05-05-13-45-22.png --]
[-- Type: image/png, Size: 15295 bytes --]

bug#22207: emacs-25 mishandles info code text on Fedora 23

[Glenn Morris]

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.

bug#19889: bug#22207: emacs-25 mishandles info code text on Fedora 23

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Thu, 05 May 2016 17:29:20 -0400
> Cc: eggert@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.

bug#19889: tex-verbatim face: don't specify :family?

[Glenn Morris]

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.