Scripting/Macroing TextObject - insert point?

Serengeti (Rhino WIP)
1

In the macro editor, paste the following:

! _-TextObject _Height=1.0 _Rotation=0
_Font "Arial" _Italic=_No _Bold=_No
_CreateGeometry=_Curves _GroupOutput=_Yes
_AllowSingleStrokeFonts=_No _LowerCaseAsSmallCaps=_No
_AddSpacing=_No _UseTextCenterToPosition=_No
"The quick brown fox"
0,10,0

Here, it doesn’t accept the point coordinates at the end, and places the text at some random spot…

If you remove the 0,10,0 line and run the macro again, it will ask you for the insertion point, if you then type 0,10,0 it will place it at the right spot…

I don’t understand what’s going on, but I’m finding it currently impossible to script/macro TextObject and have a pre-determined insert point. :confounded:

@DanBayn I know you were playing with this awhile back, did you notice this?

Thanks, --Mitch

2

Hi Mitch,

Yes, this is a problem, and they are working on it (for the first SR). FWIW, the text appears wherever your cursor happens to be. Try this and you will see that happening:

import rhinoscriptsyntax as rs
text = "Hello World"
pt = rs.GetPoint("Select a spot")
rs.Sleep(1000)
if pt:
    rs.Command("_-TextObject " + chr(34) + text + chr(34) + chr(32) + str(pt), True)

During that 1 second pause, move your cursor somewhere away from your pick point.

Here is the tracking:

https://mcneel.myjetbrains.com/youtrack/issue/RH-42018

Dan

3

:anguished:

4

OK so this was fixed according to youtrack, so I set about testing and it seems to be much better, thanks!!!

HOWEVER…

What I notice now - previously hidden because of the other bug - is a change in how the text is placed relative to the insertion point from V5 to V6. It concerns the “descenders” in a line of text, those letters that extend “below the line” - i.e. lower case g, j, p, q, y.

In V5, the insertion point Y value represents the line on which the text is placed, the descenders (if any) extend below the insertion line and the rest of the letters above (i.e. the text “sits” on the line through the insertion point).

In V6, if there are no descenders in the line, it behaves as in V5. However, as soon as there is one descender in the text, the entire line of text is moved up so that the bottom of the descender is on the line, and the rest of the text is above it.

You can try it yourself:
In V5, call TextObject, use some standard font like Arial, check create curves, use “hello world” as the text and 0,0,0 as the insertion point.
Now, change the text to “jello world” and do it again. You can see the two texts line up on the same horizontal line.

image
image.png984×404 23.5 KB

Now, do the same in V6. (you need the latest Beta, the one with the insertion point bug fixed). You will see the difference.

image
image.png1007×450 31.2 KB

None of the “vertical justification” settings seem to make any difference
(but it shouldn’t matter anyway for a single line of text)

  • First, IMO, this is totally wrong relative to standard typographic rules…
  • Second, this makes it impossible to determine exactly where a line of text will be placed, as it now depends on whether the text has descenders or not…

I sincerely hope this situation can be addressed… @alain ?

–Mitch

6

Hi Mitch, I think this is one for @lowell, I’ll ask

7

OK, also for @lowell:

This command is still pretty messed up…

If I run the TextObject (dialog) command with some multi-line text, set it somewhere then run the -TextObject (dash) command:

  1. the previously entered multiline text doesn’t show up, only the first line - I understand that limitation
  2. but then you can’t type anything to change the text
  3. the command line options no longer show up (font, height etc)
  4. there is a bunch of whitespace on the command line and
  5. finally you only get the insertion point prompt, and then the whole previous multiline text is inserted.

There also seems to be no command line option for left-right-center or vertical justification, which will be critical if one needs to match objects created with Text.

There are a bunch of other little glitches related to the adoption of rtf and annotation styles in the command, the result being that this function is now very unwieldy, you have to jump through a lot more hoops to get what you want. For me, the usability factor went down to practically zero.

As I have stated previously, I doubt the usefulness of having added rich text features to this command, especially that in the (rare) case that one might really need them, you can still do what you want with the normal Text command and just Explode to get the curves.

–Mitch

8

I’ll have a look at this last one.

9

@Helvetosaur @DanBayn - Hi Mitch, Dan- I think this is all working as expected in the latest here. I’m not sure it got into the last beta though. Thanks for the report(s).

-Pascal

10

Not fixed in the 28.11 build. Will see if it comes in one of the next dailies.

Edit - OK< got the 29.11 build and the placement seems correct now, thanks!

– Mitch

11

So, fixing the ascender/descender alignment bug seems to have solved most of the problems for my auto single line text conversion script for V6… The alignment isn’t perfect (it isn’t in V5 either), especially with right-justified blocks of text, but that’s mainly due to the fact that the single line font doesn’t exactly match the Arial text font. Might be able to tweak it some more, but for what we need, it’s good enough.

12

Good news. Thanks for reporting this.

Dan

13

RH-42772 is fixed in the latest BETA