Aidan Kehoe writes:
In fontconfig theory the -13 is pt,
That's right. If your X server is providing the right DPI for the
screen, fontconfig will automatically scale points to pixels
correctly.
From my own user of fontconfig in my own software, I do not recall fontconfig interacting with an X server.
So I guess that is then where the problem lies.
so it seems that the underlying library isn’t handling it
correctly.
I don't think that's likely, given:
PS: Surprisingly the Xemacs menus and such sale automatically, just not
this most important, main edit buffer, ..?
Most of the "menus and such" have their fonts configured through X
resources rather than XEmacs faces. I think that most likely
something is going on in the face processing, but I don't have a good
idea what that might be offhand. XEmacs *should* be passing the
fontspec directly to fontconfig, which then finds the font, and passes
that and the spec to Xft, which renders at the right scale. I don't
recall that XEmacs tries to adjust fontconfig specs in any way.
Yes, I meant the menus and such only.
On my own system this "just works", and the screens that get switched
are a Mac Book Pro 13" (2560x1600) and a Thunderbolt 26" (2560x1440).
so I should see the same effect that you do. But I don’t.
That sounds you are using macOS? Where the X server probably may do some things the Apple-way, instead of some more traditional standard Un*x.
Have you tried other fonts? Do you use this font with other
applications? What are the results in those cases? (I don't mean to
"blame the victim", but with the information I have so far the only
suggestion I have that would give quick resolution is that the font is
somehow broken, and a different font would work.)
Yes, I used another font before, and the vector fonts work all the same for me in all other apps.
If the font does work correctly in other applications and different
fonts show the same behavior in XEmacs, the next step would be to check to
see if XEmacs knows the actual dimensions of the screen. You can get
this information by evaluating
(list (device-pixel-width (selected-device))
(device-pixel-height (selected-device))
(device-mm-width (selected-device))
(device-mm-height (selected-device)))
This doesn't doesn't give the right answers with both screens active
on my Mac although xdpyinfo seems to work correctly. I will
investigate that, but can't promise any results soon. It doesn't
surprise me that something weird would be going on in X since the Mac
will mirror or tile the screens at the Quartz level and authomatically
adjust things, so X doesn't actually know what's going on. But it
does suggest that XEmacs is messed up here somehow.
Btw. any chance for a new tar ball point release to get up to sync with potential changes in the development source tree from the last years?