@Alain , @Benjamin_Schnei
That still gets back to my original question - which was actually serious and has two parts…
There is currently no definition I can find of how big a space a tab stop should be. In word processing programs the default length (width) can be user-defined as a specific length in whatever the file units are - i.e. there is no defined “standard” length setting for a tab.
Given the fact above, if the tab (ASCII 009) character is to be accepted in Rhino - it appears that it is not currently - then there needs to be a place in the annotation style definition where the default length can be defined. Plus some way to locally override this for a specific item.
@Helvetosaur interesting question, nevertheless I’ve never tried to understand anything like that.
I thought every kind of text editor has a basic underlaying structure including a tab stop. I mean for sure there is an standard variable like 10 spaces or something (you can fake tabbstops with spaces). my (short) web research didn’t bring any useful results.
@Alain thank you, I reported exactly the same issue about a year ago.
If there is any chance by helping you with the verification of other bugs, I made a short list:
Because indenting is very important in programming, code editors often let you configure what gets encoded into the file (tabs or spaces) and how much space is used on the screen when you press the Tab key but in this case, because the editing control generates RTF, pressing the Tab key inserts \tab into the Rtf string and shows it on the screen using a certain amount of space. Both of those attributes don’t seem to be configurable which is not surprising or expected for a such a text editing control. Another example is Notepad (plain text editor). Pressing the Tab key encodes an ascii tab character in the text and draws 8 spaces on the screen. The 8 spaces (also not configurable) have nothing to do with what gets stored in the text (file).
The bug here is that even though \tab is inserted when the Tab key is pressed it gets remove at some point as the string is passed around in Rhino. I hope that makes sense.
I’ve recently had to export a lot of layouts and DXF files with parametrically generated text. In the beginning I tried to use text fields with tab stops but gave up and I’m creating most charts as multiple columns. No tab stop, no problem