I was reviewing the changes related to the DPI/scaling behavior in the text-input form, and I’d like to clarify a few points to ensure the implementation behaves consistently across different displays.

About the DPI conversion formula
float displayPoints = Math.Max(1f, Options.Size * 72f / Math.Max(1, DeviceDpi));
Could you confirm what unit Options.Size is stored in?
If it is already in points, this conversion might actually be reducing the font size incorrectly.

If it represents pixel size at 96 DPI, then the more accurate formula should be:
Options.Size * 96f / DeviceDpi

Have we tested this logic on monitors with different DPIs? My concern is that the resulting font size may become too small on high-resolution displays, which seems related to the issue this PR is trying to address.

About the dynamic modification of Anchor properties
I also noticed the ApplyDpiSafeLayout() method adjusts the button anchors at runtime:
btnOK.Anchor = AnchorStyles.Bottom | (btnOK.Anchor & AnchorStyles.Right) | AnchorStyles.Left;
btnCancel.Anchor = AnchorStyles.Bottom | (btnCancel.Anchor & AnchorStyles.Right) | AnchorStyles.Left;
Changing anchors programmatically—especially in multiple places such as the constructor, Shown, OnDpiChanged, and nudTextSize_ValueChanged—can lead to unpredictable layout behavior.

Have we considered:

Wrapping layout updates with SuspendLayout() / ResumeLayout() to avoid flickering?

Setting anchors properly in the designer and using a TableLayoutPanel for more reliable responsive layout?

Introducing a guard flag (e.g., _isApplyingLayout) to prevent re-entrant calls?

I’m raising these points just to better understand the intent and ensure the layout behaves predictably across DPI changes. Thanks in advance for the clarification!