GNU bug report logs - #17457
24.4.50; REGRESSION: "Invalid font name: -outline-Lucida Console-normal-normal-normal-mono"

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 17457 in the body.
You can then email your comments to 17457 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.50; REGRESSION: "Invalid font name: -outline-Lucida
 Console-normal-normal-normal-mono"
Date: Sat, 10 May 2014 18:57:50 -0700 (PDT)

Subject line says it all.  No problem in Emacs 24 or prior releases:

M-: (font-info "-outline-Lucida Console-normal-normal-normal-mono")
["-outline-Arial-normal-normal-normal-sans-20-*-*-*-p-*-iso8859-1"
"Arial-12.0" 20 23 0 0 19]

In this build, however, I get this:

Debugger entered--Lisp error: (error "Invalid font name: -outline-Lucida Console-normal-normal-normal-mono")
  font-info("-outline-Lucida Console-normal-normal-normal-mono")

In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-04-29 on ODIEONE
Bzr revision: 117031 monnier <at> iro.umontreal.ca-20140429151607-qnkgbymwfaj5ut08
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/snapshot/trunk
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'
 LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
 -Ic:/Devel/emacs/include''

Message #8 received at 17457 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: 17457 <at> debbugs.gnu.org
Subject: RE: bug#17457: 24.4.50; REGRESSION: "Invalid font name:
 -outline-Lucida Console-normal-normal-normal-mono"
Date: Sat, 10 May 2014 19:07:05 -0700 (PDT)

Works with all builds through 2013-06-17, this build:

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-06-17 on ODIEONE
Bzr revision: 113024 eliz <at> gnu.org-20130617163040-8hmzci370q4argze
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 CFLAGS=-O0 -g3 LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

Regression introduced before this (broken) build:

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-06-18 on LEG570
Bzr revision: 113050 handa <at> gnu.org-20130618145521-fvpc5viqtc85j4j4
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/usr --enable-checking CFLAGS='-O0 -g3'
 CPPFLAGS='-DGLYPH_DEBUG=1 -I/c/usr/include''

Message #11 received at 17457 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 17457 <at> debbugs.gnu.org
Subject: Re: bug#17457: 24.4.50; REGRESSION: "Invalid font name:
 -outline-Lucida	Console-normal-normal-normal-mono"
Date: Sun, 11 May 2014 07:40:54 +0300

> Date: Sat, 10 May 2014 18:57:50 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> 
> Subject line says it all.  No problem in Emacs 24 or prior releases:
> 
> M-: (font-info "-outline-Lucida Console-normal-normal-normal-mono")
> ["-outline-Arial-normal-normal-normal-sans-20-*-*-*-p-*-iso8859-1"
> "Arial-12.0" 20 23 0 0 19]

What do you get in prior releases, and why do you think that output is
correct?

This is in "emacs -Q", btw, right?

Message #14 received at 17457 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17457 <at> debbugs.gnu.org
Subject: RE: bug#17457: 24.4.50; REGRESSION: "Invalid font name:
 -outline-Lucida	Console-normal-normal-normal-mono"
Date: Sat, 10 May 2014 22:23:41 -0700 (PDT)

> > Subject line says it all.  No problem in Emacs 24 or prior releases:
> >
> > M-: (font-info "-outline-Lucida Console-normal-normal-normal-mono")
> > ["-outline-Arial-normal-normal-normal-sans-20-*-*-*-p-*-iso8859-1"
> > "Arial-12.0" 20 23 0 0 19]
> 
> What do you get in prior releases, and why do you think that output is
> correct?

In prior releases (Emacs 23 through 24.3) I get what I showed above
for prior releases.  Why should I think it is not correct?  Why
should Emacs suddenly start treating it as invalid?

OK, yes, it seems weird that the font info returned seems to be for
a different font in this case!  I'll grant you that perhaps there is
an Emacs bug there to be fixed.

But at least in previous versions Emacs did not claim the font was
invalid.  I don't see why it would be invalid (either the Lucida
font or the Arial font that Emacs apparently used to think it was
looking at).

Lucida Console is in fact the font currently in use in the frame
where I ask for the value (when I test with my setup, which uses
that font by default).  This is what the frame parameter `font'
value is:

"-outline-Lucida Console-normal-normal-normal-mono-14-*-*-*-c-*-iso8859-1"

Where did I get the value of the arg I pass to `font-info'?
From here: (append fontset-lst (x-list-fonts "*")), where
FONTSET-LST is this;

(let ((fontset-lst  (fontset-list)))
  (setq fontset-lst
        (delete "-*-*-*-*-*-*-*-*-*-*-*-*-fontset-default"
                fontset-lst))
  ...)

I map `font-info' over the above list composed of `fontset-list'
fonts and `x-list-fonts' fonts.  I have been doing so for a
long time.

I really hadn't noticed until now that for the Lucida font `font-info'
apparently returned information for a different font (Arial).  But in
general it has worked well.  The info I use from `font-info' is just this:

(format
 "pixelsize: %s, pixelheight: %s, offset: %s, compose: %s, ascent: %s"
 (aref font-info iii) (aref font-info (+ iii 1))
 (aref font-info (+ iii 2)) (aref font-info (+ iii 3))
 (aref font-info (+ iii 4)))

And that seemed to be OK generally, but I admit that I didn't
check that it is always using the right font.  What I can say is
that the values for those parts(in previous versions) are different 
for different fonts.  And for a font that is not yet loaded I do get
a nil value returned from `font-info'.  Now, with the builds since
2013-06-18, I get an invalid-font error instead.

> This is in "emacs -Q", btw, right?

Yes.  And no - it makes no difference: Both with my setup and 
with emacs -Q I get the same behavior, both for previous versions
(where Emacs raises no error and returns the vector above) and
for the reported regression builds.

`font-info' is supposed to return either font info or nil if the
font is not yet loaded.  In my case the Lucida font is loaded
(even for emacs -Q).

Message #17 received at 17457 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 17457 <at> debbugs.gnu.org
Subject: Re: bug#17457: 24.4.50; REGRESSION: "Invalid font name:
 -outline-Lucida	Console-normal-normal-normal-mono"
Date: Sun, 11 May 2014 19:03:36 +0300

> Date: Sat, 10 May 2014 22:23:41 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 17457 <at> debbugs.gnu.org
> 
> > > Subject line says it all.  No problem in Emacs 24 or prior releases:
> > >
> > > M-: (font-info "-outline-Lucida Console-normal-normal-normal-mono")
> > > ["-outline-Arial-normal-normal-normal-sans-20-*-*-*-p-*-iso8859-1"
> > > "Arial-12.0" 20 23 0 0 19]
> > 
> > What do you get in prior releases, and why do you think that output is
> > correct?
> 
> In prior releases (Emacs 23 through 24.3) I get what I showed above
> for prior releases.  Why should I think it is not correct?  Why
> should Emacs suddenly start treating it as invalid?

Because it indeed _is_ invalid, see below.

> OK, yes, it seems weird that the font info returned seems to be for
> a different font in this case!  I'll grant you that perhaps there is
> an Emacs bug there to be fixed.

Yes, there was a bug, and it has been fixed in the current code.
That's why you started to get that error.

> But at least in previous versions Emacs did not claim the font was
> invalid.  I don't see why it would be invalid (either the Lucida
> font or the Arial font that Emacs apparently used to think it was
> looking at).

There's nothing wrong with the fonts, it's just that you are using an
invalid specification of a font.

> Where did I get the value of the arg I pass to `font-info'?
> >From here: (append fontset-lst (x-list-fonts "*")), where
> FONTSET-LST is this;
> 
> (let ((fontset-lst  (fontset-list)))
>   (setq fontset-lst
>         (delete "-*-*-*-*-*-*-*-*-*-*-*-*-fontset-default"
>                 fontset-lst))
>   ...)

But the above doesn't yield "-outline-Lucida Console-normal-normal-normal-mono",
it yields this:

  "-outline-Lucida Console-normal-normal-normal-mono-*-*-*-*-c-*-iso10646-1"

And if I use this longer string, there's no problem:

  M-: (font-info "-outline-Lucida Console-normal-normal-normal-mono-*-*-*-*-c-*-iso10646-1") RET
  => ["-outline-Lucida Console-normal-normal-normal-mono-16-*-*-*-c-*-iso10646-1" "Lucida Console-12.0" 16 16 0 0 13]

Likewise with this more loose spec:

  "-outline-Lucida Console-normal-normal-normal-mono-*-*-*-*-*-*-*"

> I map `font-info' over the above list composed of `fontset-list'
> fonts and `x-list-fonts' fonts.  I have been doing so for a
> long time.

There must be some other factor at work here, because I don't
understand how you get your truncated spec.

Font specifications that start with a dash "-" are XLFD specs, and
they must be built according to certain rules to be valid.  (See the
node "Fonts" in the User manual for some details.)  Your string starts
with a dash, which means it's an XLFD spec, but it has too few
components (the parts between dashes) for an XLFD spec, so Emacs
rejects it as invalid.  Previously, it didn't detect the problem, and
would return information about some semi-random font, whose
particulars depend on which fonts are installed on your system.  E.g.,
on one of my systems I get Arial, like you, but on another I get this:

  ["-outline-STIX-normal-normal-normal-mono-16-*-*-*-p-*-iso8859-1" "STIX-12.0" 16 24 0 0 16]

> I really hadn't noticed until now that for the Lucida font `font-info'
> apparently returned information for a different font (Arial).  But in
> general it has worked well.  The info I use from `font-info' is just this:
> 
> (format
>  "pixelsize: %s, pixelheight: %s, offset: %s, compose: %s, ascent: %s"
>  (aref font-info iii) (aref font-info (+ iii 1))
>  (aref font-info (+ iii 2)) (aref font-info (+ iii 3))
>  (aref font-info (+ iii 4)))

This info will be incorrect if you get it for the wrong font.  The
pixelsize and pixelheight parameters are different, for starters.

> `font-info' is supposed to return either font info or nil if the
> font is not yet loaded.

I don't see a problem with a function that signals an error when
passed invalid input, even though that fact is not stated in the
documentation: we rarely state that in other cases.  For example:

  M-: (string-width 1) RET
  => error

Message #20 received at 17457 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 17457 <at> debbugs.gnu.org
Subject: RE: bug#17457: 24.4.50; REGRESSION: "Invalid font name:
 -outline-Lucida	Console-normal-normal-normal-mono"
Date: Sun, 11 May 2014 10:19:58 -0700 (PDT)

> There must be some other factor at work here, because I don't
> understand how you get your truncated spec.

Yes, sorry.  This is what I was doing, with var FONT as input:

(save-match-data
 (let ((xlfd-regexp  "\\`\\(-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*\\)\
-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*\\'"))
   (or (not (string-match xlfd-regexp font))
       (setq font  (replace-match "\\1" nil nil font)))))

I truncated it because I am not interested in anything except the
first 6 fields of the XLFD string.  And previously, or so I thought,
`font-info' worked OK with such a truncated font spec.

(And - see below - I thought that allowed me to get font info for
some fonts that otherwise did not give info.  I did not realize that
`font-info' was in fact giving me incorrect info for those fonts.)

I then filtered out the case of a literal (string= font "-*-*-*-*-*-*"),
then passed the FONT to `font-info'.

I have fixed my code now so that the main feature works.  But `font-info'
still complains about some of the fonts I have.  I've wrapped the
`font-info' call in an `ignore-errors' to ignore that, but this means that
I cannot get font info for those few fonts.  So be it.

FYI, here are some problematic fonts.  It is no doubt the addition of
extra fields that makes them invalid.

-outline-MingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-big5-0
-outline-MingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso10646-1
-outline-MingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso8859-1
-outline-MingLiU_HKSCS-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-big5-0
-outline-MingLiU_HKSCS-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso10646-1
-outline-MingLiU_HKSCS-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso8859-1
-outline-PMingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-big5-0
-outline-PMingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso10646-1
-outline-PMingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso8859-1
-outline-SimSun-ExtB-normal-normal-normal-mono-*-*-*-*-c-*-gb2312.1980-0
-outline-SimSun-ExtB-normal-normal-normal-mono-*-*-*-*-c-*-iso10646-1
-outline-SimSun-ExtB-normal-normal-normal-mono-*-*-*-*-c-*-iso8859-1

All of those fonts seem to work OK outside of Emacs.  But yes, Emacs
now rejects them - this raises the same invalid font error:

M-x set-frame-font
    -outline-MingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-big5-0

Is Emacs doing the right thing here and other applications (e.g. Outlook)
are wrong?

If you see no bug wrt this, OK.  In any case, I will close the current bug.
Thanks for taking a look.

Message #25 received at 17457 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>, Kenichi Handa <handa <at> gnu.org>
Cc: 17457 <at> debbugs.gnu.org
Subject: Re: bug#17457: 24.4.50; REGRESSION: "Invalid font name:
 -outline-Lucida	Console-normal-normal-normal-mono"
Date: Sun, 11 May 2014 20:41:59 +0300

> Date: Sun, 11 May 2014 10:19:58 -0700 (PDT)
> From: Drew Adams <drew.adams <at> oracle.com>
> Cc: 17457 <at> debbugs.gnu.org
> 
> > There must be some other factor at work here, because I don't
> > understand how you get your truncated spec.
> 
> Yes, sorry.  This is what I was doing, with var FONT as input:
> 
> (save-match-data
>  (let ((xlfd-regexp  "\\`\\(-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*\\)\
> -[^-]*-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*-[^-]*\\'"))
>    (or (not (string-match xlfd-regexp font))
>        (setq font  (replace-match "\\1" nil nil font)))))
> 
> I truncated it because I am not interested in anything except the
> first 6 fields of the XLFD string.

The right way is to replace the other fields with "*", not chop them
off.

> I have fixed my code now so that the main feature works.  But `font-info'
> still complains about some of the fonts I have.  I've wrapped the
> `font-info' call in an `ignore-errors' to ignore that, but this means that
> I cannot get font info for those few fonts.  So be it.
> 
> FYI, here are some problematic fonts.  It is no doubt the addition of
> extra fields that makes them invalid.
> 
> -outline-MingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-big5-0
> -outline-MingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso10646-1
> -outline-MingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso8859-1
> -outline-MingLiU_HKSCS-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-big5-0
> -outline-MingLiU_HKSCS-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso10646-1
> -outline-MingLiU_HKSCS-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso8859-1
> -outline-PMingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-big5-0
> -outline-PMingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso10646-1
> -outline-PMingLiU-ExtB-normal-normal-normal-serif-*-*-*-*-p-*-iso8859-1
> -outline-SimSun-ExtB-normal-normal-normal-mono-*-*-*-*-c-*-gb2312.1980-0
> -outline-SimSun-ExtB-normal-normal-normal-mono-*-*-*-*-c-*-iso10646-1
> -outline-SimSun-ExtB-normal-normal-normal-mono-*-*-*-*-c-*-iso8859-1

Yes, I think the problem is in that "-ExtB", which I think is part of
the font name, but Emacs's XLFD parser thinks it is a separate field.
Perhaps Handa-san, or someone else who knows more about fonts, could
tell how to handle these font names correctly.  It looks like a bug to
me, FWIW.

Message #28 received at 17457 <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Drew Adams <drew.adams <at> oracle.com>, Kenichi
 Handa <handa <at> gnu.org>
Cc: 17457 <at> debbugs.gnu.org
Subject: RE: bug#17457: 24.4.50; REGRESSION: "Invalid font name:
 -outline-Lucida	Console-normal-normal-normal-mono"
Date: Sun, 11 May 2014 12:23:32 -0700 (PDT)

> > I truncated it because I am not interested in anything except the
> > first 6 fields of the XLFD string.
> 
> The right way is to replace the other fields with "*", not chop them
> off.

I almost added, and will add now, that I think perhaps the reason
I did that before passing the font arg to `font-info', was mainly to
allow handling of the problematic fonts.  I did not realize, however,
that they were anyway not being handled correctly that way.  They were
tolerated, but the returned info was not relevant.

> Yes, I think the problem is in that "-ExtB", which I think is part of
> the font name, but Emacs's XLFD parser thinks it is a separate field.
> Perhaps Handa-san, or someone else who knows more about fonts, could
> tell how to handle these font names correctly.  It looks like a bug to
> me, FWIW.

I thought of that, but I don't know how the name should be parsed,
to determine that the name field has ended.  Perhaps the following
field has only a fixed number of possibilities.  But then there is
(IIRC) the possibility that fields can be missing.  IOW, is it
perhaps problematic to parse names that contain hyphens?

I closed the bug.  If appropriate, feel free to open it based on
the possibility of a parsing problem.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.