mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-04-15 18:18:05 -05:00
b088d77d58
If the user's choice of fonts can't be instantiated during initial terminal-window setup, then we now automatically try two fallback options, "client:Monospace 10" and "server:fixed", and only give a fatal error if _no_ option allows us to open a terminal window. Previously, on Wayland, PuTTY and pterm with default configuration would completely fail to open a terminal window at all, because our default font configuration is still the trad X11 "server:fixed", and on Wayland, X11-style server-side bitmap fonts don't exist at all. Conversely, in the GTK1 build of PuTTY which we're still supporting, _client-side_ fonts aren't supported, so if a user had configured one in their normal PuTTY configuration, then the GTK1 version would similarly fail to launch. Now both of those cases should work, because the fallbacks include a client-side font _and_ a server-side one, and I hope that any usable Pango system will make "Monospace" map to _some_ locally available font, and that any remotely sensible X server has 'fixed' I think it would be even better if there was a mechanism for the Conf to specify a fallback list of fonts. For example, this might be specified via a new multifont prefix along the lines of choices:client:Monospace 10:server:fixed with the semantics that the "choices:" prefix means that the rest of the string is split up at every other colon to find a list of fonts to try to make. Then we could not only set PuTTY's default to a list of possibilities likely to find a usable font everywhere, but also, users could configure their own list of preferred fallbacks. But I haven't thought of a good answer to the design question of what should happen if a Conf font setting looks like that and the user triggers the GUI font selector! (Also, you'd need to figure out what happened if a 'choices:' string had another 'choices' in it...)