Open gdiazlo opened 3 years ago
The same issue is in the dump file too.
I was thinking we should not mess with font sizes in devdraw. It is really fontsrv's job. Fontsrv should serve double-sized font on hidpi.
But how will fontsrv know where a program is rendered? Acme might start in a hidpi display and then be moved to a non hidpi display. Isn't that the devdraw domain?
How about serving an additional /mnt/font-hidpi
?
But how would that work? I can't see a solution that does not involve either merging/integrating devdraw and fontsrv, or change the application (or both)
I think both approaches would be based on the visual size, instead of the pixel size, hiding the pixels sizes from applications (if we modify devdraw and fontsrv) or users (if we modify applications).
Probably this problem does not justify the kind of modifications to the programs which would be needed to solve it. Even if it is more work for a user, some scripting could solve most of the pain :-?
Is this what causes selecting a large font to result in acme clipping text? Is there any work around?
A couple of months back we introduced a new message on acme's ctl file which allows setting up the font for the selected window. I quickly did an F+/F- script to increase/decrease fonts of the selected window. Super useful when sharing screen on videoconferences.
But because devdraw autoscales font size on hidpi displays, the font size returned by acme windows ctl is not the one we should write back to get the same font size.
For example, If I read the current window font size:
and write the message
echo font /mnt/font/IBMPlexSans/27a/font | 9p write acme/2ctl
Then the font get a size of:
It is easy to fix on the F+/F- script, but not sure how would be a fix to devdraw and its clients. acme needs to know the real font size to calculate its UI, and devdraw needs to recalculate the font size for hidpi support.
I usually have acme on a non hidpi external monitor and didn't notice.