DEV Community: Arsh Singh

Tk scales your fonts for high DPI but not your layout

Arsh Singh — Fri, 04 Sep 2026 17:04:36 +0000

Open a Tkinter app on a display set to 150% and the text is often too big
for the boxes it sits in. This is why, and the fix that made it stop for
me.

The bug

MultiTerm is a terminal emulator
whose interface, terminal grid and chrome alike, is drawn on Tk canvases.
At 100% scaling it looked right. On a display set to 150%, the labels grew
by half and the bars they sat in did not. The shell picker label was cut
off under the next control. The terminal grid was unaffected, because its
cell size is measured from the font. Everything positioned with a literal
number was wrong.

What Tk does on Windows

Tk has one DPI setting: tk scaling, the number of screen pixels in a
typographic point. At 96 dpi that is 96/72, or 1.333. On a 150% display
Windows reports 144 dpi and, if the process has declared itself DPI-aware
(MultiTerm calls SetProcessDpiAwareness(1) at startup so text is not
blurred), Tk sets tk scaling to 2.0.

That value affects exactly one thing: fonts whose size is a positive
number, which Tk reads as points. A size 10 font becomes 13 pixels at 100%
and 20 pixels at 150%. Correct, and automatic.

Nothing else is touched. canvas.create_rectangle(0, 0, 200, 32) is 200 by
32 pixels on every display. pady=6 is six pixels. A HEADER_HEIGHT = 44
constant is 44 pixels. The text scaled by 1.5, the box by 1.0, and the gap
between those two numbers is the bug.

Scaling the layout to match is not enough on its own. If you multiply every
constant by tk scaling / 1.333, layout and fonts each scale once, which
sounds right, until you use a pixel-sized font somewhere, or override the
scaling for a test, or run on a machine where Tk's number and yours were
computed differently. Two mechanisms, two opinions.

The fix: one factor, applied by you

Take the scale away from Tk and apply it yourself, to fonts and layout
alike. This is the whole of MultiTerm's ui.py, minus docstrings:

import os

BASE_SCALING = 1.3333333   # Tk's pixels-per-point at 96 dpi
PT_TO_PX = 1.3333333
SCALE = 1.0

def init(root):
    global SCALE
    override = os.environ.get("MULTITERM_UI_SCALE")
    if override:
        SCALE = max(0.75, min(4.0, float(override)))
    else:
        reported = float(root.tk.call("tk", "scaling"))
        SCALE = max(1.0, min(4.0, reported / BASE_SCALING))
    # Fonts are sized in pixels from here on, so keep Tk out of it.
    root.tk.call("tk", "scaling", BASE_SCALING)
    return SCALE

def px(n):
    """A design pixel, scaled for this display."""
    return int(round(n * SCALE))

def font_px(points):
    """Font size in pixels (negative), scaled. Tk never touches these."""
    return -max(6, int(round(points * PT_TO_PX * SCALE)))

Three moves.

Read the scale Tk already worked out, divide by the 96 dpi baseline, and
keep the result as a single number. At 150% that is 1.5.

Set tk scaling back to the baseline so Tk stops scaling anything itself.

Give fonts negative sizes. In Tk a negative font size means pixels, and Tk
leaves pixel sizes alone. font_px(10) returns -13 at 100% and -20 at
150%, the same pixel sizes Tk would have chosen, except now they come from
the same factor as the layout.

Then every pixel constant goes through px():

HEADER_H = px(44)
canvas.create_rectangle(px(8), px(6), px(208), px(38), ...)
label_font = tkfont.Font(family=family, size=font_px(10))

Fonts and layout grow together and there is nothing left to disagree.

Test it without a high-DPI monitor

The MULTITERM_UI_SCALE override is the piece I would keep if I threw the
rest away. Set it to 1.5 and the app renders as it would on a 150% display,
on any display. MultiTerm's GUI test can be run that way and it walks the
canvas items to check two things:

no text item extends past the shape it is drawn on
no header label overlaps a control

The comment above that check reads "a clipped Command Prompt shipped once".
That is the entire reason it exists.

Things that do not work

Scaling only the layout. Fonts are then scaled twice.

Setting tk scaling to 1.0 instead of 1.333. Fonts stop scaling with DPI,
but now one point is one pixel, so a 10pt font renders at 10px instead of

Pin to the 96 dpi value, not to 1.

Reading the DPI yourself through GetDpiForSystem or similar. It works,
but Tk has already asked Windows and put the answer in tk scaling. Two
sources for the same number is how the original bug happened.

Letting the factor drop below 1.0. The code clamps at 1.0 on purpose so a
low reported DPI never shrinks the interface.

MultiTerm is a free, MIT-licensed multi-pane terminal for Windows with
workspaces, per-folder startup commands and broadcast typing. The module
above is
multiterm/ui.py.

PyInstaller silently kills every ConPTY child because it doesn't bundle OpenConsole.exe

Arsh Singh — Fri, 04 Sep 2026 17:03:23 +0000

I wrote a terminal emulator in Python. It ran fine from source. After
packaging it with PyInstaller, every shell it opened exited the instant it
started. No exception, no log line, no dialog. This post is the explanation
I wish had existed when I went looking for one.

The setup

MultiTerm runs several Windows
shells side by side. Each pane is a child process attached to a
pseudo-console, which on Windows 10 and later means
ConPTY.
The spawning goes through pywinpty:

from winpty import PtyProcess
proc = PtyProcess.spawn(["cmd.exe"], cwd=cwd, env=env, dimensions=(rows, cols))

With a normal Python install this works for cmd, PowerShell, Git Bash and
WSL.

The symptom

Build a one-file exe:

pyinstaller --onefile --windowed --name MultiTerm main.py

Run it and every pane shows "process exited" before a prompt appears. The
exit code is 3221225786, which is 0xC000013A, which is
STATUS_CONTROL_C_EXIT. The shell is saying it was killed by Ctrl+C. Nobody
pressed Ctrl+C.

Every shell fails the same way, so the shell is not the problem. It fails
before the first prompt, so it is not something the user did. And it only
fails in the packaged build, so packaging is the difference. That narrows it
down to "something PyInstaller left behind", which is still a lot of things.

What ConPTY actually is

ConPTY is not just a library call. CreatePseudoConsole starts a separate
console host process. That process owns the screen buffer, does the VT
translation, and sits between your program and the shell. The shell is a
child of the console host, not of you.

pywinpty does not rely on the console host built into Windows. Next to its
extension module it ships conpty.dll and OpenConsole.exe, the
open-source console host from the Windows Terminal project, so that ConPTY
behaves the same on every Windows 10 build instead of depending on whatever
conhost.exe the OS happens to have. You can see this in the DLL itself:
its string table contains both \conhost.exe and OpenConsole.exe. The
chain when a pane opens is

your app  ->  conpty.dll  ->  OpenConsole.exe  ->  cmd.exe

Take OpenConsole.exe away and the DLL still returns a process handle, so
the Python side sees a successful spawn. The shell then finds itself with no
console host behind it and exits. A Windows console process that loses its
console exits with STATUS_CONTROL_C_EXIT, the same code as an unhandled
Ctrl+C, which is why the exit code points you at the wrong thing. That last
step is my reading of the behaviour, not something I traced through the
kernel, but it matches what you see.

Why PyInstaller misses it

PyInstaller finds binary dependencies by reading DLL import tables. It sees
that the winpty extension imports conpty.dll and winpty.dll and
bundles them. It cannot see that conpty.dll will later CreateProcess an
exe sitting next to it, because that is a string inside the DLL, not an
import. So the two DLLs travel and the two exes (OpenConsole.exe, and
winpty-agent.exe for the older winpty backend) stay in site-packages.

There is no hook for winpty in pyinstaller-hooks-contrib as of the
version I have (2026.7), so nothing fills the gap for you.

From source, the whole winpty folder is present and the exes are found.
Packaged, they are not. Same code, different neighbours.

The fix

Add the helpers yourself. This is the build script MultiTerm ships,
trimmed:

import os, subprocess, sys

HELPERS = ("OpenConsole.exe", "winpty-agent.exe", "conpty.dll", "winpty.dll")

def winpty_dir():
    import winpty
    return os.path.dirname(os.path.abspath(winpty.__file__))

def main():
    wp = winpty_dir()
    cmd = [sys.executable, "-m", "PyInstaller", "--noconfirm", "--clean",
           "--onefile", "--windowed", "--name", "MultiTerm",
           "--hidden-import", "winpty"]
    for helper in HELPERS:
        path = os.path.join(wp, helper)
        if os.path.isfile(path):
            cmd += ["--add-binary", "%s;winpty" % path]
    cmd.append("main.py")
    return subprocess.call(cmd)

The line that matters is --add-binary <path>;winpty. The destination has
to be the winpty folder so the exe lands next to conpty.dll inside the
extracted bundle, which is where the DLL looks. Drop it at the bundle root
and the shells die exactly as before.

In a spec file, the equivalent is listing the four paths in binaries=[...]
with 'winpty' as the destination.

A second problem you hit right after

With the console host in place, cmd and PowerShell work. Git Bash still
dies. Different cause.

PyInstaller's one-file bootloader extracts everything to a temp folder,
puts that folder at the front of PATH, and exports _MEIPASS2 and a few
_PYI_* variables so the frozen interpreter can find itself. A child shell
inherits all of it. Git Bash then resolves some of its own DLLs to the
bundled copies at the front of PATH and crashes on load.

Strip that out before spawning anything:

def child_env():
    env = dict(os.environ)
    bundle = getattr(sys, "_MEIPASS", None)
    if bundle:
        norm = os.path.normcase(os.path.abspath(bundle))
        env["PATH"] = os.pathsep.join(
            p for p in env["PATH"].split(os.pathsep)
            if p and os.path.normcase(os.path.abspath(p)) != norm)
        for key in list(env):
            if key.startswith("_PYI") or key in ("_MEIPASS", "_MEIPASS2"):
                del env[key]
    return env

This applies to any frozen Python program that launches child processes,
not only terminals.

How to recognise it

Works from source, fails packaged.
Child exit code 3221225786 (0xC000013A).
PtyProcess.spawn raised nothing.
While the packaged app is running, dir %TEMP%\_MEI*\winpty shows two DLLs and no exes.

If all four match, add the binaries and move on with your day.

MultiTerm is a free, MIT-licensed multi-pane terminal for Windows with
workspaces that remember their folders and startup commands, and broadcast
typing across panes. The full build script is
tools/build_exe.py.