Commandline has unwanted space

I also would like to report one UI BUG (at least I consider it that way) which could be resolved super quickly by the programmers at “McNeel” in the next Rhino 7 SR update. It’s the extra, unwanted space in the Command line that destroys the visible portion of the text field after using the _PolygonCount command. Some other commands also cause that mess for no reason. Here is an example showing how the bug basically makes the user experience bad:

Command: _PolygonCount
There are 15ᅠ269 quadrilateral polygons and 34ᅠ374 triangular polygons in this selection

There would be 64ᅠ912 total triangular polygons in this selection after forced triangulation

Here is how the Command line looks like before running the _PolygonCount command:

This is how wrong the Command line looks after running the _PolygonCount command:

Running any command afterwards makes the Command line look even worse:

(moved to new topic)
hi Bobi, I cannot repeat that here,

can you send me your _SystemInfo?

Sure, here is my System information:

Rhino 7 SR25 2022-11-22 (Rhino 7, 7.25.22326.19001, Git hash:master @ 2a680490f96a04550d1f39158b859c4f7739d024)
License type: Commercial, build 2022-11-22
License details: Cloud Zoo

Windows 10 (10.0.19044 SR0.0) or greater (Physical RAM: 16Gb)

Computer platform: DESKTOP

Standard graphics configuration.
Primary display and OpenGL: NVIDIA GeForce GTX 1660 Ti (NVidia) Memory: 6GB, Driver date: 11-13-2022 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 526.98
> Accelerated graphics device with 4 adapter port(s)
- Windows Main Display attached to adapter port #0

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)

Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 11-13-2022
Driver Version:
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 6 GB

Rhino plugins that do not ship with Rhino
D:\PROGRAMI\Rhinoceros 6\Plug-ins\Stereoscopic 3d viewport\StereoView.rhp “StereoView”

Rhino plugins that ship with Rhino
C:\Program Files\Rhino 7\Plug-ins\Commands.rhp “Commands” 7.25.22326.19001
C:\Program Files\Rhino 7\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 7\Plug-ins\RhinoScript.rhp “RhinoScript”
C:\Program Files\Rhino 7\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 7.25.22326.19001
C:\Program Files\Rhino 7\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 7.25.22326.19001
C:\Program Files\Rhino 7\Plug-ins\rdk_ui.rhp “Renderer Development Kit UI”
C:\Program Files\Rhino 7\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 7\Plug-ins\RhinoCycles.rhp “RhinoCycles” 7.25.22326.19001
C:\Program Files\Rhino 7\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 7.25.22326.19001
C:\Program Files\Rhino 7\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 7\Plug-ins\Displacement.rhp “Displacement”

Do you use any display scaling in Windows?

Yes, I do. I use a 4K TV as my working monitor and scaling is set to 200%. That extra spacing is only happening on several commands while others do not have it.

What font settings do you use for your command prompt? Tools > Options > Appearance

I use the following font settings:

I just tried 100% scaling from the Windows 10 settings and this time the Command line looked fine:

Most likely the 200% scaling is causing the extra space in the Command line.

can you try with default font? Segoe UI?

Strange things happen. When I switched to Segoe UI, the font size slightly increase and looks like calculating the render mesh of a box is fine, but doing so with the render mesh of a sphere added a blank space… Both were just built in a new scene sitting next to each other.

This is how the same letters look with the Arial font:

Ah… I suspect there is something going on with the , character in your system, as this is what I see:

1 Like

My Windows 10 is English US but set to use Bulgarian metric system. In Bulgaria we don’t write 18,752. We write 18 752 instead, adding a blank space between every 3 digits from backwards. I wonder why Rhino adds a free space between the two sentences…

I see, I can repeat your issue when switching to Bulgarian, so that space is throwing things off.
RH-72137 Bulgarian Regional format in Windows line spacing issue in Command Prompt

1 Like

Yes, most likely that’s the issue as you find out above. The same numbering order is also used in a variety of other countries other than Bulgaria, too. Here, we use a decimal comma, this is why we use a space between every 3 digits. For example, 18 752,5 means “eighteen thousand seven hundred fifty-two and five tenths”.

Out of curiosity, since the spacing bug is being described with “Release target 8.x”, does that mean that it may be left unresolved in Rhino 7?

Hi Bobi -

Only severe crashes or regressions are fixed in Rhino 7, so, yes, this is something for an 8.x release at the earliest.

OK, so most likely it will not be fixed for Rhino 7? I reported that bug at least twice since the release of Rhino 7 back in 2020, but instead of resolving it on time by the programmers at “McNeel”, I was advised to increase the height of the command line with two extra rows, which is unacceptable, because it will heavily reduce the working space in the viewports… I’m forced to often click on the Command line and use the arrow keys or the mouse scroll wheel to navigate across the buggy spaced lines there. :slight_smile:

Wim is right. This will not be changed in V7. It risks too many unintended consequences.

This sort of thing is specifically why we have a WIP process.
Then we can fix them, clean up the unintended effects, and get the fix in the new version.

Have you looked at your setup in the V8 WIP?
If not, please do.
Report any issues in the Serengeti category and provide us with the specific settings to reproduce the problem.


I had the impression that the Rhino 7 Service releases that appear after the initial release of the program are updates that fix known bugs while the program is still alive, i.e. not replaced on the market by its successor, the completed Rhino 8. As I mentioned above, I reported that bug at least twice in the previous years, however, it was ignored at the time.

As for Rhino 8 WIP, I tried several of its releases so far and it has way too many disadvantages compared to Rhino 7. I also created a dedicated topic where I wrote my impressions from the Rhino 8 WIP with bugs and other issues that were the most noticeable from my point of view. Rhino 8 WIP from last month still had the majority of those unresolved. I just downloaded the latest WIP and it still has those unnecessary UI elements such like 3 dots on each bar. Some SubD icons are still too dark, despite that I reported that long time ago as an issue for Rhino 7’s UI (maybe last year?). There is a major issue in the latest Rhino 8 WIP with positioning of the Gumball after extruding a surface into a polusurface and then exploding the latter into separate surfaces. That was also reported by multiple people during the entire year 2022.

hang in there with v8… there is a reason it’s sill labeled WIP and not release candidate, lots of work still in progress.

Well, lets hope that once that bug related to localization is being resolved on Rhino 8, it will also come on Rhino 7, as well. :slight_smile: Never give up.