Fetch the actual screen resolution and add that to the list of available resolutions for the resX and resY menus.
I.e. If the pattern contains '*' for the resX and resY fields (i.e. instead of '0') then we end up with the menu containing "0, 100, NNN", which makes for a really good demonstration of how scaling fonts without knowing the true screen resolution can lead to very wonky results. Even if the values in the pattern are '0' you still get the true DPI as an option in the menu.
When you specify a size for a scalable font, you should use points, never pixels. Points are a physical unit of measurement. There are always 72 points per inch. Never more or less. So to scale fonts properly on a screen the scaler needs to know the resolution of the display in pixels per inch in order to render text at a measurable physical point size. In the current X11 world it is still up to the user to correctly specify the actual screen resolution when requesting a scalable font to render text with, and this is now possible with this change to Xfontsel.
So with the actual correct resolution selected from the resX and resY menus (and if the resolution figures are accurate and if the display hasn't been scaled by the hardware or, e.g. XrandR) then choosing any avaliable point size will show the sample text with a height on the screen physically matching the chosen point size. To that end the default pixelSizeList resource has been changed to just "0", as it should never be changed, and instead the default "pointSizeList" resource has been extended with a list of reasonable real-world sample (deci)point sizes.
Note this comes from my recent and ongoing efforts to adapt my decades old .xinitrc and related configs to make full use of a new Apple XDR Pro display (6016x3384 pixels (700x394 millimeters)) with Xquartz running in full-screen full-resolution mode. I can now start very similar looking X11 sessions and applications, with physically matching window dimensions and font sizes, on both my old 27-inch iMac at 109dpi and on my new display at 218dpi using the exact same scripts and configuration files on each. It's a bit messy (mostly due to the horrors of xrdb and the need to create many crazy entries in a new fonts.alias file, and some ancient applications are too incredibly pixel oriented to be usable (xfig and xv are my current nightmares, with xpdf also giving a few headaches), but overall everything else that I use works quite well.
Ideally this change would not really be necessary (though it would still prove quite useful I think). Xft and the Xserver should cooperate to always translate zeros from the resX and resY fields of a font request into the actual screen resolution, ideally per screen being rendered to if that is possible (and if not overridden by a "-dpi" parameter to the Xserver which should then be used instead) (or, as another optional global override, the Xft.dpi resource value if that is provided, though it should not be provided normally by default).
[My copyright for these changes is hereby assigned to the X Consortium, as per the current copyright notice in the source.]