XFLD fonts broken on w32 since around font-backend merge

XFLD fonts broken on w32 since around font-backend merge

[Jason Rumney]

Since sometime around the font backend merge, fonts specified as XFLD no 
longer work on Windows.

  emacs -Q -fn "-*-DejaVu Sans Mono-normal-r-*-*-13-*-*-*-c-*-iso8859-1"
results in Emacs not starting, and the following message on stderr:
  Font `-*-DejaVu Sans Mono-normal-r-*-*-13-*-*-*-c-*-iso8859-1' is not 
defined.

Emacs now seems to only recognize that font if the slant is specified as 
"normal" rather than "r", and the spacing as "m" (previous versions of 
Emacs on Windows only used "c" and "p" here, but up until the merge of 
font-backend code, Emacs seemed to be happy using a font with 
FONT_SPACING_MONO when "c" was specified).

Re: XFLD fonts broken on w32 since around font-backend merge

[Jason Rumney]

Jason Rumney wrote:
> Emacs now seems to only recognize that font if the slant is specified 
> as "normal" rather than "r", and the spacing as "m" (previous versions 
> of Emacs on Windows only used "c" and "p" here, but up until the merge 
> of font-backend code, Emacs seemed to be happy using a font with 
> FONT_SPACING_MONO when "c" was specified).
It turns out that only the latter is causing the failure, so I've 
changed the w32 font backends to report FONT_SPACING_CHARCELL for all 
monospaced fonts rather than FONT_SPACING_MONO.

The use of normal/italic/oblique for the slant field in 
font_unparse_xfld could still be causing problems elsewhere (eg there 
seem to be reports still open of some fonts no longer working with the 
freetype and xft backends, which could be caused by inconsistencies in 
xfld names like this, at least while XFLD is still being used as our 
primary format for names).

bug#316: marked as done (XFLD fonts broken on w32 since around font-backend merge)

[Emacs bug Tracking System]

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


Your message dated Mon, 26 May 2008 15:14:58 +0100
with message-id <483AC5E2.1070203@gnu.org>
and subject line Re: XFLD fonts broken on w32 since around font-backend merge
has caused the Emacs bug report #316,
regarding XFLD fonts broken on w32 since around font-backend merge
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don@donarmstrong.com
immediately.)


-- 
316: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=316
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 5723 bytes --]

From: Jason Rumney <jasonr@gnu.org>
To: emacs-pretest-bug <emacs-pretest-bug@gnu.org>
Cc: 
Subject: XFLD fonts broken on w32 since around font-backend merge
Date: Mon, 26 May 2008 15:01:29 +0100
Message-ID: <483AC2B9.5000007@gnu.org>

Since sometime around the font backend merge, fonts specified as XFLD no 
longer work on Windows.

  emacs -Q -fn "-*-DejaVu Sans Mono-normal-r-*-*-13-*-*-*-c-*-iso8859-1"
results in Emacs not starting, and the following message on stderr:
  Font `-*-DejaVu Sans Mono-normal-r-*-*-13-*-*-*-c-*-iso8859-1' is not 
defined.

Emacs now seems to only recognize that font if the slant is specified as 
"normal" rather than "r", and the spacing as "m" (previous versions of 
Emacs on Windows only used "c" and "p" here, but up until the merge of 
font-backend code, Emacs seemed to be happy using a font with 
FONT_SPACING_MONO when "c" was specified).






[-- Attachment #3: Type: message/rfc822, Size: 2796 bytes --]

From: Jason Rumney <jasonr@gnu.org>
To: emacs-pretest-bug <emacs-pretest-bug@gnu.org>
Cc: 316-done@emacsbugs.donarmstrong.com
Subject: Re: XFLD fonts broken on w32 since around font-backend merge
Date: Mon, 26 May 2008 15:14:58 +0100
Message-ID: <483AC5E2.1070203@gnu.org>

Jason Rumney wrote:
> Emacs now seems to only recognize that font if the slant is specified 
> as "normal" rather than "r", and the spacing as "m" (previous versions 
> of Emacs on Windows only used "c" and "p" here, but up until the merge 
> of font-backend code, Emacs seemed to be happy using a font with 
> FONT_SPACING_MONO when "c" was specified).
It turns out that only the latter is causing the failure, so I've 
changed the w32 font backends to report FONT_SPACING_CHARCELL for all 
monospaced fonts rather than FONT_SPACING_MONO.

The use of normal/italic/oblique for the slant field in 
font_unparse_xfld could still be causing problems elsewhere (eg there 
seem to be reports still open of some fonts no longer working with the 
freetype and xft backends, which could be caused by inconsistencies in 
xfld names like this, at least while XFLD is still being used as our 
primary format for names).