"SmallSystem" font problems on Windows

I just noticed that my apps, when built for Windows, have trouble with fonts sizes. (They’re built with an older Xojo version from '14 or '15, not sure.)

  1. When using “SmallSystem” for the font name, the font remains large, like for “System”.

  2. When using either Win7’s or Win10’s font scaling (they seem to work differently), the fonts do not scale in my Xojo-made app but scale well in “regular” apps.

Are these known problems? Have recent Xojo versions tackled them?

Also, while working around the first problem is rather simple (by also setting an explicit font size instead of using “0”), I wonder if there are work-arounds for the second problem as well.

That sounds like a HiDPI issue. Is your system running at other than 100% for font scaling?

Tim, yes, that’s what I meant by font scaling. I’ve set it to 150%.

I suspect that the only way to sort that is with the newer Xojo and the HiDPI support flag for Windows.

Well, the latest IDE certainly can’t handle the 150% on Win7 - in many places, the text overflows the button or label or editfield’s space, cutting off the text. In other places, no scaling happen, making the text hard to read because it’s too small.

Is Win7 still supported by Xojo?

Windows 7 way to scale is peculiar : it scales separately text and other controls, so it becomes very difficult for applications, not only the IDE, to deal with that.

AFAIK Windows 7 separate text scaling has never been supported by the IDE.

Windows 8 and Windows 10 are much more logical in their way to handle scaling, homogeneous for all controls.

Yeah, I had already suspected that Win7 and 10 use different ways. Okay, I’ll give up on Win7 then and test with Win10.

Damn - on Windows, when I change the font prefs in the IDE’s Options window, the code in the project window is not immediately updated, but only once I close the Options dialog. That’s not right, either.

Aha! When I run a test app made with latest IDE and enable HiDPI, then everything scales up by the 150% set up in Windows 7.
Which is exactly what I expected. Without building for HiDPI, the controls do not scale up, while the text in them does, leading to a cramped UI with cut-off text.

This suggests that the IDE is NOT using HiDPI mode. If it did, it might be actually usable on Win 7 (and 8) at 150% font scaling.

I also see that SmallSystem does NOT lead to a smaller fonts on Windows, ever. Which I find to be quite the bug, though I’m afraid that Xojo calls this an OS dependency and won’t fix this as “it’s always been like this”. Any other opinions on this?

Indeed. I remember reading it is not HiDPI aware yet.

Windows 10 uses Segoe UI as System font. There is a separate, bitmapped font called Small System, but frankly, you don’t want to use it.

“SmallSystem” acts as a meta font name in Xojo, just like “System” does, so it should map to a smaller font on all platforms, I’d say.

I also found that Win10 is slightly better at scaling 150%, but Xojo’s HiDPI mode screws that up a little in some places, again:

For instance, without HiDPI checked in the Xojo project, Win10 seems to let the app render everything at 100% (contrary to how Win7 did it), and then simply scales everything up to 150% afterwards. That way the dimensions of controls fit everywhere, but due to the odd scaling factor, we get ugly scaling artifacts, such as the fonts and lines all being a bit blurry.

OTOH, with HiDPI enabled, Xojo controls render properly at the higher resolution in Win10, making everything crisp.

However, some elements do not get upscaled as they should, such as the window title and the menubar. Which means they end up with very small text, making it hard to read again.

At 200% scaling, which is a more likely scaling with HiDPI screens, this issue is even more severe. The text become tiny. For a menu, that’s quite bad.

Is that a known issue? I’d think that must have been quite obvious in testing when HiDPI support was added, so why wasn’t this addressed?

Try multiple displays. It won’t switch scale factor. :frowning:
I really don’t want to rant but I’m frustrated every day. So many things are half finished and called ‘Considered Beta’ so therefore barely usable (to me). Windows, ‘New’ Framework, 64 bit support etc.
I almost spend more time on all kind of workarounds than actually getting things done.
I take my hat off to people that were able to squeeze out an above average, good working, modern looking Windows project.

I am in the process of adapting an app already in the MAS to Windows, and it is a darn pain. I reported in another thread that TextArea.StyledText.RTFData is broken since apparently 2016R1, so I spent the better part of yesterday writing my own save/load styled text routine. Today I found out that popupmenu have erratic behavior when the user selects the same value as what is already selected. In popupmenu setting the font size, if I select twice 20, I end up with 10. So today I replaced that by a bevelbutton and a ListBox.

I bumped into DLL hell as well last week. Unfortunately, as the project has been created on Mac with 2016 and all pictures are image sets, I simply cannot revert to 2015R4.1 without major work.

Tomorrow I have to address printing that seems to be off as well.

Christophe bumped into the plain box window that has a white stripe on top. I reported that on July 20, 2015, over one year ago, and posted a three lines declare workaround. How difficult is it to implement ? It does not seem to interest anybody.

This is getting out of hand.

Only Windows 8.1+ supports this. You should get a ScaleFactorChanged event in 2016r2 or higher when the system settings or monitor changes DPI- please file a Feedback report if you don’t.

Filed two bug reports, then:

<https://xojo.com/issue/44880> “Windows: SmallSystem should have smaller size than System but doesn’t”

<https://xojo.com/issue/44879> “HiDPI on Windows: Window title and menubar not scaled correctly”