And yet another fun annotation style trap

Every time I open a certain file, I get a missing font message, despite the fact that my annotation styles have been repeatedly cleaned and purged and this font is not referenced by any of them… or so I thought.
I sent in a largish file to tech with this problem. I already spent a number of hours trying to track it down, writing some diagnostic scripts and individually going through the 200+ texts in the file to see which ones might be causing this.

I actually found a few texts that had an annotation style that uses Arial, but the individual text referenced a different, non-installed font (Helvetica Light), so I went in and fixed them all, one by one by re-assigning Arial to the individual text objects. Saved the file with that nice feeling that comes from thinking I had finally vanquished the problem. Yeah, right.

Re-opened the file and got the missing font message… #%$%@$!!

So now I finally am able to repeat the bug. Below is a file with one of these objects. Open it and select the text, in Properties you will see that the annotation style is Standard 02 (font: Arial), but the text actually references Helvetica Light (not installed)

image

OK, attempt to fix by changing the font to Arial via the dropdown:

Cool, it seems to have worked. Yeah, right.

Unselect the text. Reselect the text. In Properties it shows Arial for half a second, then reverts to Helvetica Light (not installed).

Sheesh.

CantChangeFont2.3dm (1.8 MB)

Hi @Helvetosaur,

You need to highlight the text before changing the font to Arial (or Adobe Caslon Pro or whatever):
image
Otherwise you are just changing the font for whatever you type next, not the existing text.
CantChangeFont2 001.3dm (45.3 KB)

Regards
Jeremy

However, that has replaced one style override with another. If you want to set the text back to the standard style you do this:

CantChangeFont2 002.3dm (43.6 KB)

And yet another trap I fell into - multiple times. Foolish of me to think that selecting the text object in the Rhino window would also automatically select the text in the text edit window. I fully understand why one needs to select the text or part of it to change the font - so you can mix 'n match fonts in the same text - but it just makes the whole thing pretty unwieldy.

And, as a by-product of this reasoning - it’s now virtually impossible to detect a text block that has multiple fonts or a font that is not installed.

If you run the following on the file above, it will print “Arial”

import rhinoscriptsyntax as rs
a_objs=rs.ObjectsByType(512)
for obj in a_objs:
    if rs.IsText(obj): print rs.TextObjectFont(obj)

Or on this one as well:
BunchOfText.3dm (1.8 MB)
(as the first element is in Arial)

This is the first time I have seen the possibility to “Remove overrides” - thanks. However, that still doesn’t 100% address the problem, as I may not want to remove the overrides from all the text blocks I have, just specific ones that contain specific fonts. And it doesn’t seem possible to detect those currently*.

*Edit: looks like I’m going to need to parse the following result and find stuff that is not what I want:

import rhinoscriptsyntax as rs
a_objs=rs.ObjectsByType(512)
for obj in a_objs:
    if rs.IsText(obj):
        rhobj=rs.coercerhinoobject(obj)
        txt_formula=rhobj.Geometry.TextFormula
        print txt_formula

Result:
>>> {\rtf1\deff0{\fonttbl{\f0 Arial;}{\f1 Helvetica Light;}}\f0 \fs23{\f1 All\u233?e de la Vorsiaz\par}}

For example this seems to be able to detect blocks of text with multiple fonts:

import rhinoscriptsyntax as rs
a_objs=rs.ObjectsByType(512)
for obj in a_objs:
    if rs.IsText(obj):
        rhobj=rs.coercerhinoobject(obj)
        txt_formula=rhobj.Geometry.TextFormula
        if r"\f1" in txt_formula:
            print "Contains multiple fonts"
        else:
            print "Single font"

The ‘remove overrides’ is specific to the selected text, so that should still be possible.

As for visually identifying which text has an overridden font, Arial and Helvetica are probably the hardest combo. Easier if one was Old English, say:

.

However there is a bug or design flaw in the remove overrides feature: if only part of the text has been overridden then the cursor has to be in the overridden part for the option to appear in the dropdown. In the attached example, you don’t get the option until you place the cursor in the final word. If your fonts are less distinguishable the location of the override may be near impossible to determine: the option should be presented in every case (if there are no overrides it can’t do any harm to present it anyway).
CantChangeFont2 003.3dm (46.3 KB)

Hi guys -
There’s a lot going on here…
For now, I’d say that (1) when multiple fonts are used in a text object, the Properties panel should show that the style is overridden, and (2) there should be a way to select overridden annotations.

The first one is somewhat on the list as RH-47285 in that Pascal comments that if there is more than one font in a piece of text, the Font entry should read <varies>. I can write it out in a new YT item to focus on that part. - RH-63692

As for the second one, we have SelDimOverride but that only works for dimensions. I’ll get a more general “annotations” command on the list as well. - RH-63693
-wim

1 Like

Hi,

To address the 1st problem, you do not need to select the text before changing the font. One reason that this is confusing is that the controls try to support 2 modes at once: editing the string as a whole, and editing sub strings.

Users who want to edit the string as a whole do not want to have to swipe select the string every time before changing a property. So if the edit control doesn’t have focus, like when you select an annotation in the viewport, changing the font will be applied to the whole string as if it was completely selected.

In Mitch’s case it didn’t work because of a specific bug: changing to Arial was being ignored because in this case Arial happens to be the substituted font for the ... (not installed) font. The bug has been fixed. I hope that makes sense.

The other issues will be looked at next.
Thank you for reporting it.

1 Like

RH-63706 is fixed in the latest Rhino 7 Service Release Candidate