I’m drawing plans with model units set to centimeters, but I can’t set the scale of a layout detail in any unit other than millimeters. The unit dropdown for the detail scale doesn’t let me switch to cm or any other unit.
Because of this, the automatic scale label is wrong: a detail that should read 1:100 displays as 1:10.
Steps to reproduce:
Set model units to centimeters
Create a layout and a detail
Set the detail scale → only mm is available as the unit
Add an automatic scale label → it shows 1:10 instead of 1:100
Here is what it should, and did, display before the last update:
Apple macOS Version 26.5.2 (Build 25F84) (Physical RAM: 32GB)
Mac Model Identifier: MacBookPro18,2
Language: en
.NET 8.0.14
Metal GPU Family Apple 7
Metal GPU Family Common 3
Metal GPU Family Mac 2
Graphics processors
Apple M1 Max
Color LCD (1728 x 1117 @ 120.00Hz)
GPU Vendor: Apple
Rhino plugins that do not ship with Rhino
/Users/shooner/Library/Application Support/McNeel/Rhinoceros/packages/8.0/Corgi/0.8.6/net7.0/Corgi.rhp “Corgi” 0.8.6.0
Thanks for the report and the video, that made this easy to chase down.
i was able to repeat this in the latest (8.34.26202) — a detail that is truly 1:100 with cm model units shows 1:10 in the scale label. It worked correctly in the SR34 release candidate, so this regressed in the final SR34 build. The label is currently mixing layout units (mm) with model units (cm), which is exactly the factor of 10 you’re seeing.
In the meantime, setting your layout units to centimeters to match the model (Document Properties > Units > Layout units, let it rescale so the page size stays the same) makes the label read correctly again.
@Gijs switching layout units to cm does fix the scale label, but it breaks all my annotations: they now display 10x larger (see attached). That’s manageable on a new project, but going back and fixing every annotation in every existing project is quite tedious.
@Japhy thanks for chasing this down and filing RH-97134, much appreciated.
@dale you’re technically correct, the values in that dropdown are consistent. But my plans get printed, and no one looking at the sheet sees the context of that drop-down menu. What they see is a scale label that says 1:10 on a drawing that’s actually 1:100.
Thanks all for digging into this. Having read through the developer ticket, I’d like to make a case for one specific outcome rather than just re-arguing the workaround.
The core of it is that "1:#" is currently ambiguous about whether # is expressed in page units or model units. Before c01b361 it was page units; after, it’s model units. That’s why the two tickets pull against each other: RH-96873 needed the conversion gone, and this one needs it back. Any resolution that just picks a side re-breaks the other.
But an architectural scale label is conventionally unit-less. “1:100” means one of anything on paper equals a hundred of the same thing in the world. It doesn’t carry a unit on either side, which is precisely why it survives being printed, photocopied, and read by someone who never sees the document settings. If "1:#" reduced both lengths to a common unit before forming the ratio, it would print 1:100 for a true 1:100 detail regardless of what the model and layout units happen to be. RH-96873’s meters-model case gives 1:1 instead of “1:1000M”. This one gives 1:100 instead of 1:10. Neither needs a units caveat.
That’s essentially what’s already suggested in the ticket:
Reduce page_length_mm : model_length_mm to 1:N, or alternatively emit explicit suffixes on both sides so the label is at least self-describing. The first seems closer to what the field is for.
On the mm-vs-cm layout convention:
I take the point that mm is standard, and I’m not arguing otherwise. But it’s noted separately in the ticket that the locked unit dropdown isn’t explained by c01b361 and needs its own look, so at minimum the UI is telling users the setting is available when it isn’t. And as long as any mismatch between model and layout units is possible, the label shouldn’t silently render a wrong number. It fails quietly, on the one artifact that leaves Rhino and gets handed to a contractor.
Would a unit-less ratio be feasible for "1:#", or is there a compatibility concern with existing files that depend on the current reading?
This can be fixed with the “Scale all sizes” button, scale factor 0.1 in your annotation style page. If you have any dimensions in use in model space, you’ll also need to adjust your Model Space Scale for that annotation style, by reducing it to 1/10th
Also if the text is the wrong size (maybe it was imported from a DWG or DXF) but the annotation style is other wise correct, use the ScaleTextHeight command to scale the text height about the text insertion pt.
The keeps the text located properly by changes the text height by a scale so the bigger text is still big, and small text is small. ScaleTextHeight
Changing the layout unit to something other than mm in metric and other then inches for imperial should be avoided. The layout unit in all Rhino metric templates is mm. The layout unit in all Rhino imperial templates is inches.
Why: It is very likely to cause friction and incorrect results with annotation scaling, linetype scaling, and detail callouts down on the layout.
Here are a few reasons why this is the case:
Rhino communicates with the printer in mm.
Paper is purchased mm in the EU and inches in Imperial countries.
MM is the unit in which print drivers are written and do their low lever communication.
Typical drafting scales are expressed in these units. 1:500 or 1mm=500 M or CM or whatever the model unit is.
Meters or CM as the model unit is fine and common.
If there is some other regional convention for the layout being CM it is not typical EU practice, please share.
If you have a file acting badly, you may need to insert it as a exploded block into a new model created from one of our default templates. Use import Layout command to insert the layouts from the original file or make them fresh again. Feel free to send the file Attn Mary to tech@mcneel.ocm and use our large file upload system if required.
Rhino is not locked down in the units area, and maybe it should be. But in the spirit of freedom, you can change this but with the above information, you can see why you should not and be prepared for incorrect looking annotation, hatch and even linetype scaling if you do.
Sincerely,
Mary Ann Fugier
Note:
These are results from a simple Google search not even directly related to Rhino, but on Printing Page Setup.
Thanks for the fast support, and for logging RH-97175.
To be clear about my position: I’m agnostic about layout space units. I’m happy to keep layouts in mm. My only requirement is being able to display drawings at a specified scale and have the label say so correctly.
On the proposal itself: the explicit mixed-unit formats (“1 mm : 10 cm”) would certainly remove the ambiguity, and I can see they’re useful for cases like decimal-feet plans. But I wonder why not also simply restore a true unit-less ratio label as an option: reduce both lengths to a common unit before forming the ratio, so a genuine 1:100 detail reads 1:100 whatever the model and layout units are. That’s the conventional architectural scale notation, it needs no suffix, it simplifies reading for contractors and it resolves RH-96873 and this issue at the same time. It seems more straightforward than adding formats users have to pick correctly.
Thanks again for the quick turnaround on this, have a nice weekend.
I can only apologize for what happened here. It’s not our intention to try to change international conventions on how scales are formatted on drawings. This change was now reverted and “cherry-picked” into 8.35. The first public release with this fix should be next Tuesday as a service release candidate.
If you need this fixed now, please let me know if you want to revert to 8.33 or an in-house 8.35 with the fix.
-wim
