emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Ping! Re: `font-spec` unable to retrieve :name of font


From: Eli Zaretskii
Subject: Re: Ping! Re: `font-spec` unable to retrieve :name of font
Date: Thu, 22 Oct 2015 17:59:00 +0300

> From: Alexis <address@hidden>
> Date: Thu, 22 Oct 2015 19:48:09 +1100
> 
> Ping! Does anyone have any thoughts on the below? TIA!

Sorry for not responding earlier.

> Having tried various alternatives, i now use Inconsolata-g as my preferred 
> general Emacs font:
> 
>    http://leonardo-m.livejournal.com/77079.html
> 
> using Xft as my Emacs font backend.

Using such fonts is unwise, see below.

> In trying to use the `company-quickhelp` package, however, i discovered that 
> it wasn't working due to a call to `pos-tip-show`, which in turn essentially 
> calls:
> 
> (font-spec :name (frame-parameter (window-frame (selected-window)) 'font))
> 
> This call results in:

> (error "Invalid font name: 
> -unknown-Inconsolata-g-normal-normal-normal-*-13-*-*-*-m-0-iso10646-1")
> 
> which is, of course, due to the dash in the font name; the X Logical Font 
> Description Conventions:
> 
> http://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/XLFD/xlfd.html#fontname_syntax
> 
> exclude the dash/hyphen as a valid in-field character.
> 
> What, if anything, can be done about this? Should this be considered a bug, 
> or "working as intended"?

Emacs's font handling is deeply entrenched in the XLFD spec.  That is
true even on platforms that don't support XLFD, such as MS-Windows.
So this is not a bug, it's the intended behavior, the code is working
as designed.

That said, I had a similar problem with fonts named like Foobar-12,
see commit 7d5a7a4 which solved that.  (The original problem is
described in the discussion that started in
http://lists.gnu.org/archive/html/help-emacs-windows/2015-06/msg00001.html.)
That problem could be solved because the part after the dash was a
number, and a font's family cannot be a number.  I don't know if we
can do the same with this case.  Which "family" names are we allowed
to reject, exactly?  Don't forget that the weight field of the XLFD
spec, which follows the family, uses single-letter codes (although
AFAIK "g" is not one of them); we ought not to trick ourselves into
accidentally treating weight as part of the font name.

I guess we need advice from some expert on fonts, but I don't know if
we have such a person on board.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]