Tag/Text Improvements

[bosborne]

Goal: Remove the differences between Text and Tags and streamline the process

Specific improvements (in no particular order):

1. With the Text changes in 2017 - Text 3/32" Arial is not exactly the same size/letter spacing/line spacing as Tag 3/32" Arial - Needs to be fixed ASAP  (ref: http://bdmackeyconsulting.com/revit-2017-text-editor-vs-tag/)

2. Leader Location for Tags - Text allows us to specify 6 leader locations (3 on the left and 3 on the right) - Tags only let us go middle of tag each side.

3. Leader Type as Instance Parameter - We have too many text/tag styles that literally vary only in the leader head (Arrow, slash, dot, open circle, etc).  Any time an edit has to be made, we have to edit many tag types rather than just one.  Same goes for Text.  Making leader arrowhead an instance would clean things up significantly.

4. Aligning of tags and Text - Text will naturally line up with other text and text leaders.  Tags will align with other Tags. But Tags and Text will not align with each other

5. Tag Justification as Instance Parameter - Sometimes I want the tag to be left justified, sometimes I want right justified, sometimes I want middle/top- why must I have separate types/labels to achieve this?  Make it instance based - let the actual content (data that is read) be the "Type"

6. Tag re-size like text - basically I would like to be able to resize any tag to be wider/narrower within the project on an instance basis.  Let the Label Width used in the family be the "default" upon tag creation, but allow us to change the width of any individual tag just like text.

7.Tag and Text - Opaque/transparent as instance parameters rather than type - reduce the total number of text and tag styles that users must pick from.  Allow for one setting to be the "default" (i.e. Tags and Text always default to Transparent unless the user selects to make a tag/text instance opaque after creation).

8. Allow Tag Rotation - Keep default behavior as-is, but allow for post-creation rotation (using the rotate tool) of all tags on an as-needed basis  (so "Align with Element" only governs until "overidden" by the Rotate command)

[bosborne]

Also:

9. Allow the the user to choose in the family editor whether arrowheads, justification, opacity are type or instance parameters

10. Allow the user to add in custom leader connection points (similar to MEP connectors) in the Tag Family (think about a tag that is a symbol like a triangle or a hexagon).  Currently the only way to actually control where the leader connects is to get creative with some invisible lines out in space such that the tag bounding box midpoints align with where you want the leader.

[Anonymous]

11. Ablility to change alignment of text outside of the family editor.

12. Define arrowhead style default in tag family

[bosborne]

 Brenan -

I like the idea of #12 for text as well. (wish I could kud a comment). Where we currently have the arrowhead style as a Type parameter, that could be changed to "Default Arrowhead Style" - thus allowing for the consistent creation of 15 degree arrow leaders, and the occasional instance parameter switch after creation.  I think i would prefer this to the tags/text "remembering" the last leader style used.   We use 15 degree arrows for 90% of our leaders, but we have so many different taxt/tag styles available just to enable that remaining 10%. 

[Anonymous]

I posted something similar prior to seeing this post 

http://forums.autodesk.com/t5/revit-ideas/annotation-tag-justification/idi-p/6324538 

[Anonymous]

I would like tags to utilize a "system font" like schedules do in a way. Basically have tags read a project parameter that defines tag fonts and size as a default. This way, tags wouldn't need to be rebuilt if someone wants to change a firm's standard font.

[arek_keshishian]

By tag you mean labels? I second every idea on this post btw, I think it's the most important that has to be realized.

[bosborne]

Great idea tomAtSera.  That would really streamline changes in standards.  Good analogy to the Schedule Behavior

Arek-

I mean tags (which often contain labels).  I assume tom meant the labels within tag families.  I have no idea which of these is "most" important, but realistically #2,3,5,6,7,9,11,12 are all really the same root issue.  If the factory chose to fix one of those, they likely could do all of them as they are all different instances of the same behavior (tag/text type vs instance problems)

---

[arek_keshishian]

I meant that I think ideas mentioned here on this post are relatively some
of the most important ones compared to other ideas posted so far on
RevitIdeas.

[bosborne]

Ah...my misunderstanding. Thanks for the vote. Hope we can make something happen.

[AnthonyViscusi]

Hopefully these are new:

13)  Add more than one elbow to leaders, like dont limit us

14)  Allow lines which are resident in annotation families to either:  

14a)  Autoresize based on the bounds of the text in the populated labels (looking at you view title and spot annotation symbol for instance)

14b)  Have handles once placed in the project (basically much more flexible annotation families).

[bosborne]

Anthony-
I disagree on your point #13. Simply adding leaders could be a potential error (what if the leader pointed to something that was later changed to a different type?). The danger there outweighs the benefit in my opinion. The only way something like that might work would be if the "multi leader tag" worked as follows: Tag item 1. Tag item 2. Select both tags - choose "Join Tags". If both tags read the identical information, they will combine into one tag with multiple leaders. If at any point one element is changed such that the tags are no longer equal, the tags will "unjoin" and revert back to their original positions.

#14b could be stated more generically "Make tags behave with instance parameters like any other type of family" (thus allowing instance parameters, handles that can be flexed, etc..) - which falls in line with a lot of previous comments.

[pieter7]

15) Add all caps / all lower case functionality as type property of text, so we can enforce consistency over an entire project regardless of user input

[casquatch]

All of the above + 

Add ability to create an inline view reference in a text box.

[Anonymous]

Pieter

The all caps option is a great suggestion especially for labels as these read from parameters that come from families that may not conform to the in-house standard. I think that your suggestion may need it's own post.

Darren

[bosborne]

Pieter -

Great Suggestion.  It is welcome here in this Idea, but if you do create a separate idea post for it please add a link here in the comments so anyone reading though this one can easily find and vote it up too (I'll vote for it).

Casquatch -

Great Idea as well - i think this would work almost like hyperlink in Word, except it would pull up a similar pulldown as we currently have for view reference.

[bosborne]

More good ideas here - Vote

http://forums.autodesk.com/t5/revit-ideas/annotation-tag-justification/idi-p/6324538

[casquatch]

Added a new idea for the view references in text. Also thought of having the ability to reference a view from a link.

Vote away!

[Anonymous]

• So if we use text with a '2 segment' leader, I would like to be able to move my text left and right when aligning, WITHOUT the elbow point moving. At the moment, we have to align text, Then the elbow moves, skewing the leader, so then i need to grab the grip and drag it back. 
  
  
• I second the point about leader location for tags. Stuck in the centre is terrible.
• + all the rest, they are all good points. 

[lionel.kai]

@bosborne Are you talking about a different #?, because #13 is talking about adding elbows, not tagging multiple objects (although that's a good idea, too). I'd definitely like to see the multi-elbow functionality - maybe by ctrl-clicking on the leader to add another break? or just always having a "middle" grip that can be dragged out to make a new elbow (but I can imagine that might get hard to manage for short segments, unless you make sure that the existing elbow grip ALWAYS takes precedence over the middle/new-elbow grip to avoid accidentally making a bunch of elbows). Currently, we just get really creative with putting the text on the left side when needed (to get a 2nd elbow from the text width), or by right-justifying one-line text.