GNU bug report logs -
#36288
27.0.50; Cannot use menu-set-font
Previous Next
Reported by: Robert Pluim <rpluim <at> gmail.com>
Date: Wed, 19 Jun 2019 07:49:01 UTC
Severity: normal
Found in version 27.0.50
Done: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Sun, 30 Jun 2019 16:02:46 +0900
with message-id <wl1rzb8six.wl-mituharu <at> math.s.chiba-u.ac.jp>
and subject line Re: bug#36288: 27.0.50; Cannot use menu-set-font
has caused the debbugs.gnu.org bug report #36288,
regarding 27.0.50; Cannot use menu-set-font
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
36288: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=36288
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
emacs -Q
M-x menu-set-font
select Ubuntu Mono Regular =>
"set-face-attribute: Font not available: #<font-spec xft nil Ubuntu\ Mono nil nil normal normal nil 10.0 nil nil nil ((:name . "Ubuntu Mono"))>"
I can select Ubuntu Mono using M-x customize-face. Why does
menu-set-font try to use an xft spec?
(frame-parameter nil 'font-backend) =>
(xfthb x)
In GNU Emacs 27.0.50 (build 4, x86_64-pc-linux-gnu, GTK+ Version 3.22.30)
of 2019-06-19
Repository revision: 50c5d5621cb5e6d7c86829ac4b776d81e47b2189
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
System Description: Ubuntu 18.04.2 LTS
Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS PDUMPER LCMS2 GMP
[Message part 3 (message/rfc822, inline)]
On Sun, 23 Jun 2019 22:50:11 +0900,
Robert Pluim wrote:
>
> >>>>> On Sun, 23 Jun 2019 15:34:23 +0900, YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp> said:
> >> On second thought, it seems to be better to leave the font type
> >> unspecified. Hard-coding the wanted font type was introduced as a
> >> "fix" for Bug#3228, but I suspect its reasoning is no longer valid (I
> >> couldn't find fonts.alias in the Type1 font directory in CentOS or
> >> Linux Mint). Also, probably we should set the :family font property
> >> instead of :name.
>
> Thanks, that fixed things for me, with font-backend '(xfthb x) and '(x xfthb)
>
> Iʼve not looked at Bug#3228, but at least on my Ubuntu machine I have:
>
> /usr/share/fonts/X11/Type1/fonts.alias
> /usr/share/fonts/X11/misc/fonts.alias
>
> but given the prevalence of opentype and truetype fonts, Iʼm not sure
> that thereʼs anything to worry about.
Ah, the package gsfonts-X11 seems to provide fonts.alias for URW Type1
fonts. Anyway, I think the behavior originally reported as Bug#3228
is actually consistent in the sense that "% emacs -fn courier-12" also
displays the text in "ugly" font in OP's environment.
Also, x-select-font is a function for a generic font selection dialog,
not specific to menu-select-font. So its result should not include
font type property only for menu-select-font.
I've pushed the patch to master as e2d8c1e8bcf. Closing the bug.
YAMAMOTO Mitsuharu
mituharu <at> math.s.chiba-u.ac.jp
This bug report was last modified 6 years and 21 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.