Hi, @keithscadservices. Can you write down a potentially repeatable process for us to replicate this issue, please? Attaching an example file would also be helpful. Thanks!
There’s a couple issues and a couple potential improvements. It’s been a while but I can remember one of each at least. If I dig into it you’ll actually take a look? A while back I deep dived into issues with a few different things to no avale.
@keithscadservices We are attempting to get to all posts in a more timely manner. Some slip through the cracks, but much less so now. I’m also happy to look into your previous post, if you can paste a link to it here. Cheers!
Thanks for looking into this!! This will probably be hard to fix/diagnose. Especially since I’m not really actively using Rhino (some months everyday other months not at all). I would probably have to record a drafting session to really show how/why this is a problem.
I’ve attached a file and linked a video. To have it reproduce the bug I had to open and close the file twice. I also updated since creating the file. If the font just matched/defaulted to the annotation style’s that would be just fine, not the last used. It seems to be overriding to the last used. There are work-arounds (like making sure not to delete the first char). It might also only happen when using the floating text editor. These issues don’t seem as bad right now but it might have something to do with file size, no. of text objects, or something else.
The bug wouldn’t exist if we only had one font per text object. Changing the font in a text object isn’t really common and having this feature makes the bug possible. It would be way more useful if we could change font size. But neither are necessary as we can just create different text objects for titles, headings, body, etc… I think if adding complexity makes the text features more buggy it’s not worth it. The issue I’m having is that we have a simple text feature but it has so many bugs.
An additional complain, not a bug so much, is that I can copy and paste special characters (like a bullet point for example) into the text, but I can’t get it from the drop down. Quicker access to symbols would be nice.
Simple is fine to be honest but simple + bugs isn’t, especially if they’re caused by features/options barely anyone will use.
Video Link:
TEMP - TEXT BUG TEST FILE.3dm (78.5 KB)
Steve,
I have extracted a single piece of text from Keith’s file. It displays as Arial text although it has a style applied that uses Arial Black. The style does not show any overrides. The properties panel shows the font as Arial although the text in the editable window is displayed in Arial Black.
If you click that text then the displayed font name changes to Arial Black. The text in the viewport doesn’t change.
If you double click the viewport text to bring up the edit window, that shows the font s Arial Black while the properties panel shows it as Arial.
I suspect the issue is specific to Arial Black as previously explored here: TEXT reverting away from chosen font - #3 by jeremy5
TEMP - TEXT BUG Extract.3dm (30.2 KB)
If you open the file in the R9 beta, the style recognises that there is a font override. This can be removed and the text behaves consistently. Wim pointed out in that thread that text handling had been rewritten for R9 and the results are encouraging.
Regards
Jeremy
It does do it with other fonts. I actually use Jost in my standards now. But you might be onto something. It’s way worse when I’m using Jost. Not sure if that’s just a coincidence obviously but who knows.
Edit: Thanks for diving so deep into this one Jeremy!!
@keithscadservices @jeremy5 I’m happy to look further into this when I have time–this week, hopefully. I’m passionate about typography (and all things Rhino-related, obviously).
I was able to successfully document this as repeatable and filed a bug report for both Rhino 8.35 and Rhino BETA.
RH-97713 Text Editing in Properties & Dialog is Still Broken
