emacs-devel
[Top][All Lists]
Advanced

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

Re: bad default font on Windows mingw64


From: Stephen Leake
Subject: Re: bad default font on Windows mingw64
Date: Mon, 22 Jul 2019 15:10:21 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (windows-nt)

Eli Zaretskii <address@hidden> writes:

>> From: Stephen Leake <address@hidden>
>> 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



reply via email to

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