Major Description
We have to restructure the font data and properly handle the logical fonts and the realized fonts.
the internal font structures in win32k are a mess so i dont think fixing them should block these amazing fixes you came up with here. Having these fields in FONTGDI is as wrong as having the Request* fields there. The way our structures work dont make any sense. My oppinion is to merge your fixes and continue in a subsequent PR to fix the logic about how our structs are used.
Let me describe how the internal structs for fonts work in windows:
LFONT: it is represented in user mode by the HFONT. it is merely a wish by the app what font should be used. The HFONT and ita corresponding LFONT are kept in the DC object to rememeber what font was selected to it. It stands for logical font
RFONT: it is a realised LFONT. It contains the data about what font will be evwntually be used. It contains metrics and that kind of stuff. an RFONT is a realised font. There is no handlw for that and doeant have a corresponding consept in user mode. Every dc has one and it is only used through operations on a DC object. Windows use a lot of optimization techniques with that. An rfont is only initialized when it is about to be used. When an hfont is selected it invalidates the existing rfont and it is really realises only when it is about to be used. Moreover as some hfonts are used many times windows can reuse the same rfont for the same lfont if possible.
PFT: a font table, contains several PFFs
PFF: a font file, contains several PFEs as well as a list of RFONTs which i dont know what is used for.
PFE: a font entry, contains a FG_GLYPHSET among others.Its worth noting that an RFONT keeps a pointer to a PFE and a PFF.
and:
However the work on those two outdated branches can be used as inspiration for what needs to be done to put some sense in our font structs:
https://github.com/yagoulas/reactos/commits/rfont
https://github.com/yagoulas/reactos/commits/rfont2