The question
Apply to All Game Text does not reach all of Blizzard's text, and it is not
clear it ever can. Before any more work goes into it, a decision is needed:
close the remaining gaps as they are reported, or retire the option and scope
Global Font to EllesmereUI's own text.
I understand retiring it has already been floated. This issue is to make that
call explicit and record the evidence, because the alternative is an open-ended
commitment.
What prompted it
@fource set a global font and asked why quest text and the spellbook still used
the game font. A tooltip was drafted for that (#2000, now closed), on the
assumption the toggle was the answer.
A tester then confirmed it is not. With both toggles enabled, the Premade
Groups category list still renders Questing in a different face from
Delves, Dungeons, Raids and Custom.
What the mechanism can and cannot do
EllesmereUI.ApplyGlobalFontToGameText runs once at PLAYER_LOGIN, sets
STANDARD_TEXT_FONT, and calls SetFont on every object returned by
GetFonts(). That approach is sound as far as it goes, and it survives the
obvious hazard: Blizzard calls SetFontObject("GameFontNormalLarge") at
runtime in this very frame, and because the font object was swapped, that
still lands on the custom face.
Two things it cannot reach:
- Font objects registered after login. Load-on-demand UI is not in
GetFonts() when the pass runs.
- Text that does not route through a shared font object at all. Object
swapping cannot touch a FontString whose face is set directly.
Why I am not just fixing it
I was going to propose re-running the pass on ADDON_LOADED to cover (1). That
would be a contained change, needing a processed set so the size scaling cannot
compound on a second pass. But it would not fix the reported case:
Blizzard_GroupFinder is DefaultState: enabled with no LoadOnDemand, so it
is already loaded at login. The Questing mismatch is category (2), not a
timing problem.
Category (2) has no bounded fix. Reaching directly-set fonts means walking
frames and re-applying on show, which carries taint risk, costs performance,
fights Blizzard re-applying fonts on its own refreshes, and still misses text
created later.
The scale is already visible in this repo: 912 SetFont calls across 94
files, excluding libraries, and these gaps persist despite that. Every patch
can add more, and the only detector is a user noticing, which is how this
arrived.
Options
A. Retire the option. Scope Global Font to EllesmereUI's own text. Ends the
treadmill and stops promising something that cannot be delivered.
If this is the choice, it needs more than deleting the row:
- Decide whether
gameTextScale goes too. It is a separate setting sharing the
same code path and the same once-at-login pass.
- Handle existing profiles with
applyToAllGameText = true. The pass sets
STANDARD_TEXT_FONT and rewrites font objects at login, so simply removing
the control would leave those users on a swapped font with nothing to turn it
off.
B. Keep it and fix gaps as reported. Accept it as ongoing per-patch
maintenance. Worth pairing with an honest tooltip saying it does not reach
every menu, so the next report is about a specific gap rather than the feature
appearing broken.
C. Keep it, add the addon-load re-run, accept the rest. Closes category (1)
only. Does not fix the reported case, so it may not be worth doing on its own.
Happy to implement whichever, including the migration work under A. Just not
keen to keep patching individual labels without a decision on where this is
going.
The question
Apply to All Game Text does not reach all of Blizzard's text, and it is not
clear it ever can. Before any more work goes into it, a decision is needed:
close the remaining gaps as they are reported, or retire the option and scope
Global Font to EllesmereUI's own text.
I understand retiring it has already been floated. This issue is to make that
call explicit and record the evidence, because the alternative is an open-ended
commitment.
What prompted it
@fource set a global font and asked why quest text and the spellbook still used
the game font. A tooltip was drafted for that (#2000, now closed), on the
assumption the toggle was the answer.
A tester then confirmed it is not. With both toggles enabled, the Premade
Groups category list still renders
Questingin a different face fromDelves,Dungeons,RaidsandCustom.What the mechanism can and cannot do
EllesmereUI.ApplyGlobalFontToGameTextruns once atPLAYER_LOGIN, setsSTANDARD_TEXT_FONT, and callsSetFonton every object returned byGetFonts(). That approach is sound as far as it goes, and it survives theobvious hazard: Blizzard calls
SetFontObject("GameFontNormalLarge")atruntime in this very frame, and because the font object was swapped, that
still lands on the custom face.
Two things it cannot reach:
GetFonts()when the pass runs.swapping cannot touch a FontString whose face is set directly.
Why I am not just fixing it
I was going to propose re-running the pass on
ADDON_LOADEDto cover (1). Thatwould be a contained change, needing a processed set so the size scaling cannot
compound on a second pass. But it would not fix the reported case:
Blizzard_GroupFinderisDefaultState: enabledwith noLoadOnDemand, so itis already loaded at login. The
Questingmismatch is category (2), not atiming problem.
Category (2) has no bounded fix. Reaching directly-set fonts means walking
frames and re-applying on show, which carries taint risk, costs performance,
fights Blizzard re-applying fonts on its own refreshes, and still misses text
created later.
The scale is already visible in this repo: 912
SetFontcalls across 94files, excluding libraries, and these gaps persist despite that. Every patch
can add more, and the only detector is a user noticing, which is how this
arrived.
Options
A. Retire the option. Scope Global Font to EllesmereUI's own text. Ends the
treadmill and stops promising something that cannot be delivered.
If this is the choice, it needs more than deleting the row:
gameTextScalegoes too. It is a separate setting sharing thesame code path and the same once-at-login pass.
applyToAllGameText = true. The pass setsSTANDARD_TEXT_FONTand rewrites font objects at login, so simply removingthe control would leave those users on a swapped font with nothing to turn it
off.
B. Keep it and fix gaps as reported. Accept it as ongoing per-patch
maintenance. Worth pairing with an honest tooltip saying it does not reach
every menu, so the next report is about a specific gap rather than the feature
appearing broken.
C. Keep it, add the addon-load re-run, accept the rest. Closes category (1)
only. Does not fix the reported case, so it may not be worth doing on its own.
Happy to implement whichever, including the migration work under A. Just not
keen to keep patching individual labels without a decision on where this is
going.