TkDefaultFont not set properly (i.e. like Tcl/Tk does)

[TakamotoAI]

The TkDefaultFont is set on Windows in a different (and to me obscure) way in Tcl::pTk. If I run a pure Tcl/Tk application against my Tcl/Tk installation (or I simply start the Wish console), the standard font of the menu is different to the one used by Tcl::pTk (and in my opinion far better).

Tcl::pTk

Tcl/Tk

[chrstphrchvz]

Hi Takamoto,

Your screenshots indicate that Windows DPI scaling is set to >100%, which is common for newer devices having a high pixel density display. Windows traditionally used a logical pixel density of 96 DPI (dots or pixels per inch), and many older programs contain behavior hardcoded for 96 DPI such that they have usability problems if run using a higher DPI value. So for compatibility, the default approach on more recent Windows versions is to instruct DPI-unaware programs to draw as if running at 96 DPI, and then Windows will automatically upscale the result, which will have a fuzzier appearance, but the program will at least be usable.

However, if a program works correctly at different DPI settings, it can declare itself as DPI-aware and avoid the fuzzy scaling effect. This is what is done when Tk is run from tclsh/wish, but this is not done when Tk is used through the Tcl C API, as is the case for Tcl::pTk. This is what your screenshots show.

Microsoft's recommended approach for declaring DPI awareness is to use an application manifest, which is what is done for tclsh/wish. This could potentially be done for a Tcl::pTk program packaged into a .exe, but so far my use of Tcl::pTk is limited to .pl scripts, so instead I declare DPI awareness programmatically. As I wrote at https://www.perlmonks.org/?node_id=11101747:

# Make sure to do this **before** calling MainWindow->new
if ($^O eq 'MSWin32') {
    require Win32::API;
    # See https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-setprocessdpiaware
    my $SetProcessDPIAware = Win32::API::More->new('User32', 'BOOL SetProcessDPIAware()');
    $SetProcessDPIAware->Call() or warn 'Failed to set process DPI awareness';
}

I think the scaling is the only important factor here, rather than any difference in TkDefaultFont.

Hope this helps

[TakamotoAI]

Hi Christopher,

Yes, it helped! Thank you for pointing to the DPI issue which is the cause of my problem. After some testing, I opted for the script solution, at least for now. Not recommended, but working fine.

PS: I pack my App with pp and apparently there is no option available to set the manifest (I will ask the mantainer). Third parties app (Win32::Exe, Resource Tuner) did not yeld any success in changing the manifest of the exe. But, this is something that needs me to spend more time to properly investigate it.

[chrstphrchvz]

I will go ahead and close this issue, feel free to reopen it or open a new one if you need more help.

I don't know for sure what works, but I wonder if it works to add a separate .exe.manifest file in the same directory as and named after the packed exe.

[chrstphrchvz]

Something to be aware of: very recent versions of Windows support "per-monitor DPI awareness", meaning that separate displays can use different logical pixel densities; previously, all displays would use the same logical pixel density. Tcl/Tk does not support per-monitor DPI awareness on Windows, and I believe adding support for it would be difficult. Rescaling (fuzziness) will be observed for Tk programs when toplevels are moved between displays with differing logical pixel densities. One issue encountered is that this rescaling is not done correctly for overrideredirect toplevels (https://core.tcl-lang.org/tk/info/a9ee44102b); it is not clear if this is due to a Tk bug or a Windows bug.