I do confirm that with a build around 20:00 pm yesterday CET, the font is OK, but there are a couple more transitions than with emacs28...

/PA

On Thu, 17 Nov 2022 at 02:28, Dmitry Gutov <dgutov@yandex.ru> wrote:
On 16.11.2022 15:59, Po Lu via Bug reports for GNU Emacs, the Swiss army
knife of text editors wrote:
> Pedro Andres Aranda Gutierrez<paaguti@gmail.com>  writes:
>
>> Repository revision: 83a497ee879959cd1b052fa9138adb79b480394d
> What if you update to c63d77ac6b10dc453d08afc852debc6a9a3cde36 or later?

Since this bug sounds similar or at least related to bug#58912, I
probably should comment:

Rebuilding from the latest master makes the scenario in bug#58912 much
better, in that the font size is applied correctly at the end.

It's still different from Emacs 28 in that the frame size goes through
an extra transition at the end of loading. And sometimes through 1 more
(the last one the same as the -2nd one). So sometimes I end up with a
window of 84x37, and sometimes (less frequently) 80x35. All according to
window-height and window-width.

Emacs 28 and an older build of master both end up at 80x35.

But at least the font size and family are ok now.


--
Fragen sind nicht da um beantwortet zu werden,
Fragen sind da um gestellt zu werden
Georg Kreisler

Headaches with a Juju log:
unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run a leader-deposed hook here, but we can't yet