bad default font on Windows mingw64

bad default font on Windows mingw64

[Stephen Leake]

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

With recent builds of master on mingw64, I'm getting a missing default
font; see attached screenshot of emacs -Q.

When I run my normal startup, something changes, and I a good font. But
then other windows still have bad fonts, such as the ediff control
window. I tried to step thru my normal init (not easy when I can't read
the file!), but I did not find the command that restored the font.

I'm guessing this is related to the recent harfbuzz change? I have not
tried bisect yet.

Any hints on debugging this?
-- 
-- Stephe

[-- Attachment #2: Screenshot (10).png --]
[-- Type: image/png, Size: 14814 bytes --]

Re: bad default font on Windows mingw64

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Date: Mon, 22 Jul 2019 10:02:03 -0700
> 
> With recent builds of master on mingw64, I'm getting a missing default
> font; see attached screenshot of emacs -Q.

Definitely doesn't happen to me with the current master.

> I'm guessing this is related to the recent harfbuzz change?

Unlikely, as I'm using HarfBuzz as well.  But you can invoke Emacs in
a way that instructs it to use Uniscribe instead:

  emacs -Q -xrm Emacs.fontBackend:uniscribe

If you click S-mouse-2 and select "Change Buffer Font...", what font
is shown in the dialog as the current one?

Re: bad default font on Windows mingw64

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stephen Leake <stephen_leake@stephe-leake.org>
>> Date: Mon, 22 Jul 2019 10:02:03 -0700
>> 
>> With recent builds of master on mingw64, I'm getting a missing default
>> font; see attached screenshot of emacs -Q.

> But you can invoke Emacs in
> a way that instructs it to use Uniscribe instead:
>
>   emacs -Q -xrm Emacs.fontBackend:uniscribe

That gives me a readable font. But my normal startup complains:

    Font `Courier-9' is not defined

One of my normal startup commands changes the font to "Courier-9", via
`modify-frame-parameters'. Apparently that works with harfbuzz, but not
Uniscribe.

> If you click S-mouse-2 and select "Change Buffer Font...", what font
> is shown in the dialog as the current one?

I assume that's the font that is selected when the dialog starts.

With the Uniscribe backend, it's "Courier New". "Courier" does not show
size 9.

Same for harbuzz backend.

In harbuzz, if I use that dialog to select 'fixedsys', the buffer is
readable; the minibuffer and mode bar are not. Same for "Courier", but
that does.

Selecting "Lucida Console" or "Courier New" give unreadable fonts.

-- 
-- Stephe

Re: bad default font on Windows mingw64

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Date: Mon, 22 Jul 2019 12:13:59 -0700
> 
> >   emacs -Q -xrm Emacs.fontBackend:uniscribe
> 
> That gives me a readable font.

Then I think you should step through w32hb_encode_char in an Emacs
invoked normally (only with -Q), and see what happens there.  I'm
guessing it fails for some reason.

> > If you click S-mouse-2 and select "Change Buffer Font...", what font
> > is shown in the dialog as the current one?
> 
> I assume that's the font that is selected when the dialog starts.
> 
> With the Uniscribe backend, it's "Courier New". "Courier" does not show
> size 9.
> 
> Same for harbuzz backend.

So for some reason HarfBuzz cannot use Courier New.  Strange.
Are you sure your MSYS2/MinGW64 installation is up to date?
What was the commit from which you built your previous binary, which
did work?

Does anyone else see something similar with MinGW64?

Re: bad default font on Windows mingw64

[Stephen Leake]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stephen Leake <stephen_leake@stephe-leake.org>
>> Date: Mon, 22 Jul 2019 12:13:59 -0700
>> 
>> >   emacs -Q -xrm Emacs.fontBackend:uniscribe
>> 
>> That gives me a readable font.
>
> Then I think you should step through w32hb_encode_char in an Emacs
> invoked normally (only with -Q), and see what happens there.  I'm
> guessing it fails for some reason.

w32hb_get_font returns a non-zero pointer.

hb_font_get_nominal_glyph returns 0.

So w32hb_encode_char returns FONT_INVALID_CODE (#xFFFFFFFF).

I don't have source step for hb_font_get_nominal_glyph; apparently
that's in the mingw64 harfbuzz library.

> Are you sure your MSYS2/MinGW64 installation is up to date?

The files are mostly from Dec 2018. 'find . -name "*harfbuzz*"' finds
several files, including

./var/lib/pacman/local/mingw-w64-x86_64-harfbuzz-1.7.5-2

which seems to say I've got harfbuzz 1.7.5.

> What was the commit from which you built your previous binary, which
> did work?

I just realized there are old copies of emacs-<version>.exe in
emacs/src; very nice! However, they are not compatible with the current
*.elc, so not fully functional.

The executable that gives good fonts:

M-x version says it was built on 2019-05-23

M-x report-emacs-bug says:

Repository revision: 5424436452bc0b3d8a62a8398f92d0c2db81e22b

The first executable that fails is:

Repository revision: d590b27ee4c43ba000172b4ad15762863d78aba1

So the commit that caused this problem is somewhere between those two. I
can bisect, if needed.

-- 
-- Stephe

Re: bad default font on Windows mingw64

[Óscar Fuentes]

Stephen Leake <stephen_leake@stephe-leake.org> writes:

>> Are you sure your MSYS2/MinGW64 installation is up to date?
>
> The files are mostly from Dec 2018. 'find . -name "*harfbuzz*"' finds
> several files, including

pacman -Qi mingw-w64-x86_64-harfbuzz

> ./var/lib/pacman/local/mingw-w64-x86_64-harfbuzz-1.7.5-2
>
> which seems to say I've got harfbuzz 1.7.5.

harfbuzz 1.7.5 was released by MSYS2/Mingw-w64 on Feb 2018. Current
packaged version is 2.5.3. You might consider upgrading.

FWIW I cannot reproduce this.

Re: bad default font on Windows mingw64

[Stephen Leake]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Stephen Leake <stephen_leake@stephe-leake.org> writes:
>
>>> Are you sure your MSYS2/MinGW64 installation is up to date?
>>
>> The files are mostly from Dec 2018. 'find . -name "*harfbuzz*"' finds
>> several files, including
>
> pacman -Qi mingw-w64-x86_64-harfbuzz

I had to do 'pacman -S --refresh' first, but now that's updated.

Emacs 'make' did not notice the change, so I had to to 'make clean' first

And now it works properly, so the problem was an old harbuzz library.

Perhaps configure should check for that?

Thanks for everyone's help.

--
-- Stephe

Re: bad default font on Windows mingw64

[Eli Zaretskii]

> From: Stephen Leake <stephen_leake@stephe-leake.org>
> Date: Mon, 22 Jul 2019 18:03:29 -0700
> 
> > pacman -Qi mingw-w64-x86_64-harfbuzz
> 
> I had to do 'pacman -S --refresh' first, but now that's updated.
> 
> Emacs 'make' did not notice the change, so I had to to 'make clean' first
> 
> And now it works properly, so the problem was an old harbuzz library.
> 
> Perhaps configure should check for that?

I wouldn't know what check to insert.  hb_font_get_nominal_glyph
appeared in HarfBuzz 1.2.3, and we already check for that.  I suspect
your problem was actually with Freetype, which is HarfBuzz's
dependency.

Re: bad default font on Windows mingw64

[Eli Zaretskii]

> Date: Tue, 23 Jul 2019 05:37:17 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: emacs-devel@gnu.org
> 
> > From: Stephen Leake <stephen_leake@stephe-leake.org>
> > Date: Mon, 22 Jul 2019 18:03:29 -0700
> > 
> > > pacman -Qi mingw-w64-x86_64-harfbuzz
> > 
> > I had to do 'pacman -S --refresh' first, but now that's updated.
> > 
> > Emacs 'make' did not notice the change, so I had to to 'make clean' first
> > 
> > And now it works properly, so the problem was an old harbuzz library.
> > 
> > Perhaps configure should check for that?
> 
> I wouldn't know what check to insert.  hb_font_get_nominal_glyph
> appeared in HarfBuzz 1.2.3, and we already check for that.  I suspect
> your problem was actually with Freetype, which is HarfBuzz's
> dependency.

I asked on the HarfBuzz mailing list, and it turned out that our code
implicitly assumed HarfBuzz 2.0.0 or later, by omitting a function
call which was needed before that version.  I've now added that call,
so we can indeed support old HarfBuzz versions on MS-Windows, per the
configure-time tests.

Thanks.