Very tiny fonts in the VSPAERO panel

[Toshio Otaguro]

Hi,

Thank you for keeping updating the smart platform for aircraft design.

One thing I would like to mention about the recent VSPAERO is that the fonts in the panel is too small to recognize.  This happend since OpenVSP version 3.45.0.

Please find enclosed both screenshots of v3.44.5 and v3.47.0.

Is there anything to do on the user side in order to improve the situation?

Best wishes,

Toshi

[Toshio Otaguro]

I forgot to mention about the platform.

These are OpenVSP-3.44.5-win64-Python3.11 and OpenVSP-3.47.0-win64-Python3.13, respectively.

I am running these executables on Windows11 Pro 25H2, and the locale is ja-JP (Japan).

2026年1月27日火曜日 8:03:08 UTC+9 Toshio Otaguro:

[Toshio Otaguro]

I discussed with ChatGPT and tested some suggested remedies.  I had the following conclusion.

----------

Environment:
- OpenVSP v3.47.0 (official binary)
- Windows 11 Pro 25H2
- Display scaling: 100%
- Resolution: HiDPI monitor

Issue:
The text in the VSPAERO lower console panel is extremely small and unreadable.
This started in v3.45+ and does not occur in v3.44.

What was tested (no effect):
- QT_AUTO_SCREEN_SCALE_FACTOR = 0 / 1
- QT_ENABLE_HIGHDPI_SCALING = 0 / 1
- QT_FONT_DPI
- qt.conf (DefaultFamily / DefaultSize / DefaultPixelSize)
- Windows DPI override settings

Observation:
- Other OpenVSP UI fonts are normal
- Only the VSPAERO console is affected
- DPI and scaling settings have no influence

Conclusion:
This appears to be caused by the VSPAERO console using a fixed pixel-size font
(e.g. setPixelSize) rather than point-size, likely introduced with the Qt 5.15 update.

Workarounds:
- Use CLI VSPAERO output files
- Use OpenVSP v3.44 for VSPAERO
- Rebuild from source and replace pixelSize with pointSize (confirmed fix)

This seems to be a regression introduced in v3.45.
----------

I hope the issue will be fixed in the upcoming update.

2026年1月28日水曜日 8:21:24 UTC+9 Toshio Otaguro:

[Rob McDonald]

This AI hallucination is not useful.

It seems that ChatGPT assumed that OpenVSP uses QT as a GUI technology and suggested generic fixes based on that assumption.  OpenVSP does not use QT -- version 5.15 or otherwise.

In particular, I am amused with the "confirmed fix" that of course does not actually work.

The actual most likely change that triggered this was the change from a FlTextDisplay to a FlTerminal

https://github.com/OpenVSP/OpenVSP/commit/c2d4515d3672397173864cf5fb59a47a0fc69ba3

The code that sets up the FlTerminal was added here

https://github.com/OpenVSP/OpenVSP/commit/24addd4cf588fded320c22e8fae2fb2342e589b2

FL_SCREEN is supposed to set the font to the operating system's default monospaced font.  On your machine, it is failing to find the expected font, so FLTK is falling back to some other default -- which in this case is not rendered well.

It is most likely an interaction with the Japan locale that you have set.

Rob

[Toshio Otaguro]

Thank you very much for the detailed explanation.  Now I understand the background of the issue.

It seems that my platform does not have FL_COURIER.  I will look into the font issue on my side.

Toshi

2026年1月29日木曜日 2:20:06 UTC+9 Rob McDonald:

[Toshio Otaguro]

I have studied a part of FLTK, and learned it has 16 fonts which can be found in enums::Font.  "Screen" is one of them.

When Fl_Terminal calls
    terminal->textfont( FL_SCREEN );
"Consolas" or "Courier New" will be returned on Windows (en-US), or DejaVu Sans Mono on Linux.  However, on Windows (ja-JP) it seems the OS cannot return an appropriate monospace font, and FLTK falls back to some other font, which is not readable.

On Windows, relying on FL_SCREEN to resolve a suitable monospaced font appears to be locale-dependent.  The issue might happen in other exotic locales, too.

Explicitly selecting a known monospace font such as "Consolas" (with a fallback to "Courier New") would avoid issues under ja-JP and other locales on Windows.  Is it possible to implement such selection in VSPAERO?  Of course, a logic to treat other OSs would be necessary, though.

Toshi

2026年1月29日木曜日 7:05:55 UTC+9 Toshio Otaguro:

[Rob McDonald]

Do you have the ability to compile OpenVSP yourself?

I can try switching to FL_COURIER -- or to Consolas, but each will require testing.

I hate having to use platform dependent code here, but until FLKT finds a cross-platform fix for this, we don't have a choice.

BTW, as a workaround, you can copy & paste the text out into something else where you can read it.

Rob

[Toshio Otaguro]

Thanks, Rob.

Unfortunately, I don't have an environment where I can build OpenVSP from source.

I still miss the GUI interface of VSPAERO, but the fix is not an emergency request because I usually run VSPAERO from Python API.

GUI is handy and very helpful to check the degree of convergence, though.

Thank you again for the workaround for reading the text.  That's exactly what I did on the first stage, and I confirmed that the jaggy strings are correct messages.

Toshi

2026年1月30日金曜日 4:22:47 UTC+9 Rob McDonald:

[Rob McDonald]

OK,

I've pushed up a test build with FL_COURIER 14 as the Font.  We'll see if it does any better.

The build artifact should be available in about 25 minutes here:

https://github.com/ramcdona/OpenVSP/actions/runs/21497765094

Please let me know how it goes.

It looks like FLTK / Windows is falling back to a bitmapped font.  This is the old kind of font that is stored as pixels.  These kinds of fonts don't scale up/down very well -- in this case, we have a very ugly result.

More modern fonts are stored as vectors (lines and curves) and can scale up/down much better.

Another solution suggested on the FLTK forum was to see if you could install a US / English font pack on your machine.  This would be in addition to all the fonts already installed and associated with your Japan locale.

Rob

[Toshio Otaguro]

Rob,

Many thanks for the very quick build.

I am downloading the zip file, but it is very slow.  I don't know why.

I will report the result to you some hours later.

Toshi

2026年1月30日金曜日 8:02:14 UTC+9 Rob McDonald:

[Toshio Otaguro]

OK, it seems the issue has been fixed.   Please look at the screenshot here.

Thank you very much again.  I think I can use this patch for the moment.

I learned locale can be a deep pitfall.

Toshi

2026年1月30日金曜日 10:37:44 UTC+9 Toshio Otaguro:

[Rob McDonald]

OK, I'll try that in the next release -- hopefully it doesn't cause any problems for anyone.

Locale can be messy.

We once had a bug with writing either STEP or IGES files that was related to Locale.  The STEP or IGES library should have been ignoring the locale, forcing just the 'C' locale when writing files.  I don't remember how/why, but it wasn't.

Consequently, decimal numbers were written with a comma separator with certain locales set.  Those files were not readable by downstream CAD tools.

Really supporting different languages and locales takes a ton of resources that we obviously don't have.  We're lucky it works at all...

Rob

[Toshio Otaguro]

Many thanks, Rob.

I hope you sleep well.

2026年1月30日金曜日 11:35:52 UTC+9 Rob McDonald: