Proper Font Sizes in Rhino

Hi,
it would be wonderful if Rhino was better at working with font sizes. Rhino only allows you to set the font size in cap height (see below), while the rest of the world (e.g. Adobe) uses the body height of a font. That means a 8mm font in Rhino will be much larger than a 8mm font in Adobe InDesign. Having consistent layouts between both programs becomes really difficult that way. If it was possible to enter pt sizes into the “Font Size” field in Rhino, that would make things much easier. Just like you can enter all kinds of units into the text fields in InDesign and InDesgin converts them automatically.
Jasper

3 Likes

Hi Jasper - thanks, I’ll see if the developers have any input on this.

-Pascal

1 Like

Hi @jasper,

This statement intrigues me. Back in the day when I learnt a bit about typography it was the Em height that was the basis for defining font co-ordinates and scaling (so that for a 24pt font the Em height would scale to 24 points). Even as recently as CS6, InDesign expected fonts to be sized in points and scaled the Em height accordingly. Has the world of typography turned upside down in the last few years?

I’d be really grateful if you could point me at any articles or papers that would help me get up to date on this.

Regards
Jeremy

Hey @jasper.

Just curious - how to you transfer data back and forth between Rhino and InDesign?

Where are you getting this information from?

Thanks,

– Dale

Hi @jeremy5,

first of I apologise for my somewhat provocative statement. I’m also no professional typographer, but as far as i know the em includes the decendents, which Adobes mm measurement also does - and Rhino doesn’t (see image above). From all I can find the em height is the standard. I did a little testing with the software i got avaliable to me right now and apart from all Adobe products LibreOffice and Apple Pages also use the em height, meaning a 20mm text will always fit inside a 20mm box. A 20 mm text in Rhino won’t.

My feature request is rather simple and I think not too far fetched. I want to be able to create a document in Rhino with 8pt text and another document in any other software with 8pt text and have them end up as the same size. Right now my only solution is to import a PDF i created in Adobe to Rhino, manually measure the cap height and set my Rhino font size accordingly. Somewhat fiddly.

I think it would also be nice (and not too difficult to impliment i’d think, its just a conversion) if in the document settings you could choose between different units to measure fonts (mm, pt, etc…).

Kind regards
Jasper

(I gave this a little edit as i mixed up body height (or hp height) with the em height. The em height seems to be the one that’s most commonly used to define the text size. See image above.)

1 Like

Hi @dale,

I don’t. I just want to be able to create a layout in Rhino and another document in Adobe and have them match visually. I want the font sizes to be the same.

I just tried it. Printed out a PDF with 20mm text from Rhino, Adobe, LibreOffice, Pages etc. and compare the size of the text.

Kind regards
Jasper

Hi @jasper,

If you open the attached 3dm file (below) and print the Page 1 layout at 1:1, so 1.0 mm on the paper equals 1.0 mm in the model, and then measure the height of the box with a scale, it will measure at 20 mm.

20mm.3dm (35.4 KB)

Does this help?

– Dale

Corrected

Rhino uses capital height, not the conventional em, as the measurement of font height. The box in Dale’s example has the height of the capital letters. The body height is around 28 mm, not 20 mm. Em or point size would be larger.

All text in this example created using 20 mm height in Text command:
20mmDC01.3dm (1.5 MB)

1 Like

The discrepancy is likely because of ancient history. When software and computers started replacing drafting and illustrating by hand, the industries had virtually nothing to do with each other. Both AutoCAD and Illustrator got started in the 1980s. For some reason one company chose “caps height” measurement system while another chose “body height” measurement system. This is the beauty of parallel standardization.

Early Rhino was modeled heavily after AutoCAD. And our primary goal when translating files has been to ensure that there’s lots of fidelity between AutoCAD and Rhino. So, a 12mm font in Rhino will translate to be the same physical height on page when opened in AutoCAD. Also, most architects and engineers from bygone eras did all their drafting in ALL CAPS. SO WHY WOULD YOU WANT TO MEASURE THE DESCENDERS OF A TYPEFACE, ANYWAY? (I used to get emails from architects in all caps, thinking they were yelling at me. It turns out, they just kept CAPS LOCK on all the time). Meanwhile, graphic designers wondered why anyone would EVER write in all caps. It’s SO HARD TO READ!? Computers from these days were very ignorant linguistically, too - everything was designed for English, and maybe a couple other languages that used similar glyphs. So in those Anglo-centric, early computer days, the only text that mattered to “all architects” was all-caps, in English.

The simple fix for your request would break translation to AutoCAD and other CAD systems. That doesn’t mean it’s impossible - it’s just a lot more complicated than it might look at first.

3 Likes

One thing to clarify. People are talking about Em height and Body height as though they are interchangeable: they are, except rarely, different.

And while body height can be measured on rendered characters, Em height - which is what point size scaling applies to - has no visible manifestation and cannot be reverse engineered from a render.

1 Like

I corrected my post above. I’ve seen “block height”, not “body height”, used in place of “em”.

Hi @brian,

that makes a lot of sense! I was’t aware of the historical aspect of this whole topic but of course compatibility with AutoCAD is essential for Rhino. More so than matching font measurements with Adobe.

So I think - unless AutoCAD and Rhino go hand in hand to change it together - Rhino will have to stick to the cap height measurement. At least internally. For the GUI I wish it would be possible to adjust the units and means of measurement in document properties.

Either one dropdown selector called Font Unit, with the options mm (cap height) and pt (em height).

Or two dropdowns called Font Unit (mm, pt, etc…) and Font System (cap height or em height).

Now thats this years christmas wish for me, let’s see if I get lucky :upside_down_face:

Jasper

1 Like

Yes, the terminology dates back to physical type when a character was formed on the face of a block. The Em was the size of the block, generally leaving a little white space above ascenders and below descenders. As the blocks had to be jammed together in rows all the blocks had to be the same height regardless of the height of individual characters.

1 Like

I’ve added a YouTrack issue (RH-68673) to track this feature request. Thanks for pointing it out to us!

My suggestion is that we have a global Rhino setting (not in the Text dialog) that you can switch to determine whether text is measured using cap or body height. This would be a one-time setting so that every time you create text, it’s measured the way you like.

To be honest, I’m conflicted about this design. On the one hand, it would be nice for this setting to be discoverable (on the text dialog) but also not in your way every time you create text. What do you think?

2 Likes

Should the alternative height be “body height” or “block height/point size/em”?

We might be able to always store the cap height internally, but allow for a toggle in the user interface to show what the height input is specified as (cap vs body). It could get tricky to get right when switching fonts, but I think it is possible

Agreed, I think we need to keep the internal representation of the font identical, and translate between the two metrics at creation and editing time only. I hadn’t thought about font switching - that may be a difficult thing to manage, too.

If the rationale for the new feature is compatibility with other applications like illustrator, indesign, word, PowerPoint etc then the vertical Em dimension has to be scaled to a specified height in points. If you scale cap height or body height to that number of points you won’t get that compatibility and would be better leaving things alone.