To draw the Detail Line you will need to use a little custom Python node. That’s because of the said issue, where Text Notes got a little wider when upgrading from 2016 => 2019. You can see that the Detail Line is clearly shorter than the Text Note. Here’s the result after the upgrade but just before the fix to Width Factors: However, if you don’t you can clearly see the before/after effect of upgrading the model from version 2016 to version 2019 by comparing the lines. That’s also not needed so you can get rid of that as well. Just to be able to visually inspect the change later, I also added a routine that draws a Detail Line in the view next to the Text Note. The view scale is set to 1, so we can then extract from it, the Width value, and store that away in Excel. OK, so we have all of these Text Note Types, and we create an instance of each in the Drafting View. This is obviously not needed, but at the time I was told not to worry about small fonts since they were only used for Schedules or something along these lines. Additionally I have added a little step here where types that have font size smaller than 1/32″ is excluded. We need them to account for all possible notes that can be placed in the model. Now that we have a Drafting View, we collect all Text Note types. The reason we do that is to make sure that the view exists in the model, before we go to the next step where we add Text Notes to the said view. We are also committing the transaction here using the Transaction.End node. This is important because we want to make sure that we are not measuring widths of Text Notes later, that are at different scales. We start by creating the Drafting view and setting its scale to 1. OK, so let’s talk about the first script.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |