Personalize->font size 125%: windows drawn wrong

This is apparently exactly the the same problem as the old WinXP issue relating to "normal fonts (96DPI)" vs. "large fonts (120DPI)", except that Microsoft now refers to it as "medium 125%" in the Personalize -> Display font size customization dialog.

The problem is that if the application has drawn its window to be FIXED-SIZE (as opposed to re-sizable using the lower-right-corner "pull" control) and does not also provide scroll-bars in case the fixed window size is too small to show everything, when customizing font size to be larger than 100% Windows apparently only grows the HORIZONTAL size of the window but does not also grow the window in the VERTICAL dimension.

The result is often to simply chop off the lower content of a window as intended to be drawn by the application. I have just run into this with a Sirius Player (Internet Radio) application named Stream_ON.

Here is the player window at 100% font size, showing everything it should.



And here is the same player window at 125% font size. Note the loss of the entire lower portion of the expected content and application controls.



In fact, the 100% window is 660x592 whereas the 125% window is 842x592. Sure, the application has drawn the window as FIXED and non-resizable. But if Win7 is going to widen the window by 25%, why doesn't it also increase the vertical size of the window by 25%?

Seems like the blame should be shared, both by the application developer for writing an app that is not DPI-aware, and also for Microsoft for not growing the window "overall by 25% in both directions". Again, this is not a problem new or unique to Win7, as it's been around for at least 10 years in both Win98 as well as WinXP, both of which supported "large fonts (120DPI)" customization.

Very annoying to see this carried forward into Win7 as well.


Win7 Pro X64
ATI HD4670, Catalyst 9.12

And, it is the fault of who again, oh yeah Microsoft, they should have known better, they should have predicted that some third party software maker would not take this subject matter into consideration.

Just a personal thought. . .that darn Microsoft is up to it again. . .

dsperber said:

This is apparently exactly the the same problem as the old WinXP issue relating to "normal fonts (96DPI)" vs. "large fonts (120DPI)", except that Microsoft now refers to it as "medium 125%" in the Personalize -> Display font size customization dialog.

The problem is that if the application has drawn its window to be FIXED-SIZE (as opposed to re-sizable using the lower-right-corner "pull" control) and does not also provide scroll-bars in case the fixed window size is too small to show everything, when customizing font size to be larger than 100% Windows apparently only grows the HORIZONTAL size of the window but does not also grow the window in the VERTICAL dimension.

The result is often to simply chop off the lower content of a window as intended to be drawn by the application. I have just run into this with a Sirius Player (Internet Radio) application named Stream_ON.

Here is the player window at 100% font size, showing everything it should.



And here is the same player window at 125% font size. Note the loss of the entire lower portion of the expected content and application controls.



In fact, the 100% window is 660x592 whereas the 125% window is 842x592. Sure, the application has drawn the window as FIXED and non-resizable. But if Win7 is going to widen the window by 25%, why doesn't it also increase the vertical size of the window by 25%?

Seems like the blame should be shared, both by the application developer for writing an app that is not DPI-aware, and also for Microsoft for not growing the window "overall by 25% in both directions". Again, this is not a problem new or unique to Win7, as it's been around for at least 10 years in both Win98 as well as WinXP, both of which supported "large fonts (120DPI)" customization.

Very annoying to see this carried forward into Win7 as well.


Win7 Pro X64
ATI HD4670, Catalyst 9.12

The blame here is fully on the developer. Windows can't make the determination to make a window bigger. That's what APIs and such are for. Complain to the maker.

I don't excuse the developer. Hey, I've been writing to them for many years every time I run into a new app that is yet once again not DPI-aware and produces malformed windows and truncated text strings and/or broken controls because of my "large fonts (120DPI)" in WinXP and now "medium 125%" font size in Win7. Often this falls on deaf ears, or "sorry, it's a known problem".

But in this case it WAS Microsoft that increased the horizontal size of the window by 25%! What about the 2-dimensional things inside of the window... shouldn't they grow in both directions, not just the horizontal direction?

If you're going to support text, icons, buttons, controls, etc., at an overall 125% size, why wouldn't you grow EVERYTHING by 25% in both directions?

Looking at the two screenshots I posted, it's clear that it does appear everything WAS grown by 25% in both directons... with the exception of the outer window frame itself! So despite the specific values provided by the app to spawn the window and its content, Win7 went ahead and grew everything by 25%... EXCEPT THE WINDOW SIZE ITSELF!!

In fact to be more precise, Win7 grew ONLY THE HORIZONTAL WIDTH OF THE WINDOW BY 25%, while leaving the vertical size of the window exactly what it was before. This seems like the wrong way to implement "125% fonts.

If you go ahead and grow EVERYTHING interior to the window frame by 25%, in both horizontal and vertical directions, but do NOT also grow the outer edges of the window in both horizontal and vertical dimensions as well, you are absolutely guaranteed to chop off something interior to the window frame. 100% guaranteed.

In this example, the width of the window WAS enlarged by an appropriate 25% and everything that is still visible is truly 25% larger... text, pictures, etc. It's simply that by NOT also enlarging the height of the window by 25% when you'd gone to the trouble of enlarging everything inside of it by 25% in the vertical dimension... well "hilarity is bound to ensue".

This "25% growth" was implemented by Windows 7, not the developer.

Surely there's shared blame here.

Then the developer needs to fix the problem. Again it is not Microsoft's fault. They cannot be expected to be able to determine what every third party developer is going to do, sorry, albeit it is not "MICROSOFT'S FAULT."

People have to get over the fact that a OS developer regardless of the OS (Linux, Mac, Windows) is not required to ascertain what a third party developer is going to do, hence it is not the fault of the OS if a developer cannot get its act together.

dsperber said:

I don't excuse the developer. Hey, I've been writing to them for many years every time I run into a new app that is yet once again not DPI-aware and produces malformed windows and truncated text strings and/or broken controls because of my "large fonts (120DPI)" in WinXP and now "medium 125%" font size in Win7. Often this falls on deaf ears, or "sorry, it's a known problem".

But in this case it WAS Microsoft that increased the horizontal size of the window by 25%! What about the 2-dimensional things inside of the window... shouldn't they grow in both directions, not just the horizontal direction?

If you're going to support text, icons, buttons, controls, etc., at an overall 125% size, why wouldn't you grow EVERYTHING by 25% in both directions?

Looking at the two screenshots I posted, it's clear that it does appear everything WAS grown by 25% in both directons... with the exception of the outer window frame itself! So despite the specific values provided by the app to spawn the window and its content, Win7 went ahead and grew everything by 25%... EXCEPT THE WINDOW SIZE ITSELF!!

In fact to be more precise, Win7 grew ONLY THE HORIZONTAL WIDTH OF THE WINDOW BY 25%, while leaving the vertical size of the window exactly what it was before. This seems like the wrong way to implement "125% fonts.

If you go ahead and grow EVERYTHING interior to the window frame by 25%, in both horizontal and vertical directions, but do NOT also grow the outer edges of the window in both horizontal and vertical dimensions as well, you are absolutely guaranteed to chop off something interior to the window frame. 100% guaranteed.

In this example, the width of the window WAS enlarged by an appropriate 25% and everything that is still visible is truly 25% larger... text, pictures, etc. It's simply that by NOT also enlarging the height of the window by 25% when you'd gone to the trouble of enlarging everything inside of it by 25% in the vertical dimension... well "hilarity is bound to ensue".

This "25% growth" was implemented by Windows 7, not the developer.

Surely there's shared blame here.

Nope

I have this same problem but it is with Microsoft apps also. I first noticed it with the Backup app but today it is with the Sound option off of the Control Panel. See attached/below. Does anyone have a solution?

I can't seem to find a place on Windows 7 to set the default font. I went into the personalization settings and reset to the default although it doesn't say what that is. No change. I've changed screen resolution which just changes the size of the window but the text inside changes proportionately. ????????????