Scripting Editor Displaying Incorrectly for Uncommon Resolution Screens at Nonstandard Scale on Windows 11

I am a programmer who opts to use the built-in Script Editor for coding over something like Rojo + an external editor. I am currently facing serious organizational issues due to a visual bug where lines and tabs will display incorrectly on my work laptop’s screen.

My work Laptop has an uncommon screen resolution of 2560x1600. I use a Scale setting in Windows of 125%. When editing in the Script Editor at this scale, tabs alongside other things will display incorrectly and “bug” out:

I tested that the Scale in Windows was responsible by setting the Scale to 100% and reopening the same script, where everything displays normally. Here is the same script displayed at 100% Windows Scale:

I cannot use 100% scale on this laptop screen because of its small physical size. To demonstrate, here is the Taskbar of this laptop screen at 100% scale compared to my thumbnail (As a woman, my hands are fairly small to begin with:)


This is a reasonably unacceptable workaround, hence the bug report being necessary.

Here is my system information:
OS: Windows 11 Home
CPU: 13th Gen Intel(R) Core™ i7-13700HX
Memory: 32.0 GB
GPU (0): Intel(R) UHD Graphics
GPU (1): NVIDIA GeForce RTX 4060 Laptop GPU
Screen Resolution: 2560x1600
Physical Screen Size: 16.0"

To Reproduce:
Create a new Script in any Studio instance, and lay it out similarly to the script in the provided video. Optionally, enable Rulers under File → StudioSettings → Rulers In Windows Settings, find Display Settings and set Scale to any value above 100% (I use 125% in the provided video.) Close and Re-open the Studio instance and observe changes in how the Script Editor is drawing the text.

Thank you for the bug report. We are able to reproduce the issue and have filed a ticket to fix it; we’ll reach out if we need any further information.

As a temporary workaround, you may also consider using spaces rather than tabs to align your text (the initial indentation can remain tabs), as they appear to be unaffected by the issue.

1 Like

Hi we believe we’ve addressed this with a change that will be deployed in January. In the meantime I’d suggest using the “use spaces vs. tabs” as a workaround. Thanks again!