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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 10 May 2014 22:23:41 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 17457@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