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