(EDIT) This thread started as a question about if there was a way to reference a page other than the one the auto-text was on. The answer seemed to be “No” and the thread evolved into more of a feature request discussion. At the bottom of this post you will find the original text of the question so you can follow the train of thought. Below is a summary of what this feature request would consist of (I will edit this list as it evolves):
Create a new entity in LayOut that is similar to a group but has attributes associated with it (like components or dynamic components in SketchUp). For the sake of discussion we are calling this new entity an “Assemblage”
These attributes can be auto-generated or manually entered. For instance: if the assemblage contains a SU viewport the attribute for “scale” could auto display whatever the scale of the viewport is or you can manually enter it.
Other attributes might be:
-Scene name = Displays name of scene shown in SU viewport
-Document name = name of the LayOut file where this assemblage is from. You would be able to reference assemblages from other LO files in case you break up your construction drawings into multiple files (As Nick Sonder recommends)
-Label = an abbreviated symbol to be used in drawing identifications
-Page URL = unique identifier for the page so that if the page order changes you won’t have to manually
update references on other pages.
So why do this?
The speed of revisions is (in my mind) the most powerful argument for adopting Layout. This would make the program more dynamic and easy to revise. If you need to add or remove a page everything updates.
Having clickable references inside the exported .PDF construction documents would be a very powerful feature. Especially for large sets of plans. Will help our industry become less paper oriented.
You could also create an index that updates automatically. I’ve always wanted that. And I bet there will be other unforeseen cool things that one could do with this new feature as well.
The process of entering drawing identification information would be much faster if the auto-text pulls up things like scale and scene name
It is a feature for more advanced users but LayOut is designed for Pro users. Not many hobbyists use LayOut I’m guessing. And if this is not the case this feature can be completely ignored by anyone who doesn’t like it.
Updating every drawing because a client changes some detail right before you are about to hit print and ask for that final payment is an experience we all know. Show architects how easy that revision is in the SU and LO workflow and you will turn some heads.
LayOut is due for an update of features and capability.
If clickable references are a possibility then perhaps an export to HTML and/or SVG with support of clickable references so LayOut may become a web-design tool suddenly.
Questions for you?
Do you see any adjustments to this proposed expansion that would be better?
Do you think this would be a helpful feature? How would you use it?
Do you see any other possible uses for this new functionality?
What other assemblage attributes might be helpful?
[ORIGINAL POST]********************************
I’m hoping to find a way to tweak the functionality of the auto-text so that I can reference a different page than the page where this text resides.
For example, I’m working on construction documents right now and on each drawing there are multiple references to other pages. I may have a section symbol on page 3 that tells you that you can see the section in drawing “A” on page 15. Of course I can input this manually but if I shuffle the page order or add an additional page in the middle of the document then all the references need to be changed manually.
Does what I want make sense? Is it possible? I see that I can create my own auto text but I don’t see any way that I could get that functionality.
Yes I think it makes sense for sure and I also would like to be able to automate somehow such references inside LayOut document. As for me I also don’t know how to achieve it in a current version.
Another similar feature in addition to your idea can be automatic generation/refreshing of a table of LayOut document contents (Page names and numbers).
It makes sense and could be useful. To achieve it, you would presumably need some kind of link between the text that identifies the page number and whatever it is on that page that is being referenced. That sounds like quite a tall order but not beyond the wit of man. The problem may be that you would have to be very careful in setting up the linkage. So, for example, if you were linking to a viewport on another page, the system would recognize if you moved that viewport to another page and update the reference accordingly. But if you simply reproduced that viewport afresh on the new page, the link would no longer exist.
Like many people, I show section flags on plans which relate to sectional drawings on a separate page. My flags indicate the relevant page number and section reference. It would be useful to make sure they all worked together seamlessly with automatic updating following editing.
Seems like more advanced level of referencing. The initial idea was slightly simpler:
Seems like the initial idea relies on an assumption that an object (say some viewport with a section/model view etc) more or less firmly attached to some page with its name in a document (so page name explicitly specifies its content) and only shuffling of pages order or new pages adding may affect page references specified earlier in a document.
Anyway I think that idea to reference objects (like viewports) may work even better in some cases. In other cases (for example when page doesn’t even have any viewports/named scenes, but should be referenced as well for some reason), seems like the initial idea to reference the whole “page object” whith its name and number in a list also may work fine.
Getting excited about this possibility…
The idea of being able to reference a specific viewport is more than I had initially hoped for but of course that would be the icing on the cake. Though this sounds like a big ask consider what would happen if the groups in LO could have some attributes similar to components in SU? Like names, labels, scale and page #?!
Example: I create a section drawing that consists of a viewport at a specific scale, some other geometry and a drawing label. I make this all into a group. Once this group is created I have options available in a new tray window called “group attributes”. In this new window I can see and assign all the attributes of this group. Since it contains a SU viewport it would automatically show the scale but I could also manually assign this to be something else. It would have a unique “name”. It would have a “label” which would be different than it’s unique name (more on this later). It would have an automatic entry for the “Page location” it is on but perhaps there is also a reason to make this manually override-able. I’m sure there are other attributes that could be helpful here as well.
For this example lets assign the name to be “North-South Section 1”. The Label to be “A” and we will let the scale and page number be automatic. On my floor plan I have a section symbol that shows the path of the section. This symbol takes advantage of this new functionality and uses auto text to reference this specific group’s “Label” and “Page location”. The section symbol would now display “A - A15” indicating that you can see the section drawing on page A15, drawing “A”. The reason to have a “Label” that is different than the group’s “Name” is that the names will need to be unique because that is how we keep everything linked to a specific group. Labels can be repeated since you will have a drawing “A” on almost every page.
I’m thinking that there would be some kind of fly-out menu or popup dialogue that you use to access the “group attributes” auto text. Or perhaps this would be contained inside the “Group attribute” window. You would have a list of all group names to link to and once you do that, the attributes show up.
Big bonus if this could work across documents in LO. I have adopted many aspects of the workflow shown in Sonder’s book and one thing that he does that would not work so well with what is described above is he has his construction documents in multiple LO files. So if one of the group attributes referenced file name where that group was located this would work even better. Seems like you would have to have a way to insert the other LO file into the current document. Similar to how we insert a SU file but perhaps it just gets listed as a reference rather than shown in any sort of viewport.
I bet if this were created there are many clever options that it would open up beyond what I just described. A auto-updating table of contents seems like it could be pretty easily created. Your drawing label could also automatically show the scale without having to manually enter it. Typing this up I realize that groups should probably stay the same and a new entity should be created that has the above functionality. I think “component” is already taken so it might be something like “cluster”, “packet” or “assembly”. Name suggestions?
As I typed this out I started to get pretty excited about what kind of doors it would open up. Seems like LO is due for some new features, it’s been a little while since there was an increase in functionality. What do you all think? Would you change what I outlined above? Can you see the utility of such a new feature? What other doors could it open up? What other attributes should be included?
I’m not sure I have followed the intricacies of what you suggest. Could you put it in a visual form?
As for names, what about “assemblage”? Not a common word but distinguishes it from assembly which is a recognized construction term.
Something along these lines is done in so-called 3D spreadsheets where you have different sheets that can cross-reference one another. If something moves, the linkage between sheets is maintained. The naming protocol is much like the one you and I have described for section names on a different sheet from the flags on the plan drawing.
I think this idea opens up a lot of possibilities. The only “limitation” is that the whole process will be utilized only by advanced users after all. I’m afraid that majority of users would enter and edit all such references manually despite such automation (in case if it will be implemented), just because manual referencing seems to be faster especially for small documents, which are not supposed to be edited much after referencing is done. Automatic referencing would require some extra effort from a user to figure out how it works at first place and then some effort to enter/edit attributes of objects being referenced. Of course it may save a lot of time later in case if document should be edited a lot after its initial creation. So suggested referencing logic would allow smooth and safe page order changes, new pages insertions, moving of objects from one page to another.
I still think that the initial idea of referencing of the whole page may also be useful (even in provided visual representation of an idea page name fully represents its content). And logic of referencing of pages appears to be slightly easier to understand by a user.
I would think this idea has legs. You can already group elements together in LO so it is a seemingly small step from that to being able to add attributes to the group, some or all of which can be made to show on screen (you could toggle visibility).
I don’t think there are extensions for LO but, if there were, this might be something someone with programming skills could work up.
@kirill200777 may be right that this is a bit “niche” but anything that makes SU/LO more functional for professional users has to increase its appeal against alternative software.
How would that work in practice though? How would a page that has a page reference “understand” amendments made to the page being referred to? Not saying impossible but just wondering about the mechanics.
So user would be able to add a reference to a certain page (not only current) inside any text object (label text, or drawing annotations etc) on any page in a document. So I imagine page name is for example “Section A”, and page number varies in case of new pages insertion etc. Once user added such autotext somewhere in a document, contents of this autotext (i.e. drawing name and/or page number) should be always “up to date” despite pages order changes.
This approach is less intellectual, but may also work I think.
[Edit]
It is even possible not to add extra entries into “Insert Auto-Text” menu item. It is possible to leave insertion of a current page name/number logic as is, but allow more advanced auto-text tag format, which may contain reference to a page with a certain ID: <PageNumber: PageID>
Introduction of a new concept (I mean PageID) is also not that intuitive unfortunately.
The current auto text PageName returns the number of the page it is on. What you want is to be able to refer to another page wherever it might be moved in the list. I can see that working with its name as that is whatever you define it to be. I guess that if you change its name it would be like a missing link file in LO and would be highlighted in red.
Not sure how this would work with page numbers though, especially with the built-in facility to change the start page.
I think this is true for the most part but I think that those who are really using LO to any serious degree are advanced users anyway. It’s a program aimed at professionals to try and make the whole sketchup environment something that would work for a pro workflow. For me it was the ease of revisions that made LO so appealing. And when it was first released it was next to impossible to use, very flawed and limited. But the possibility of moving a wall 3’ in your SU model and having all your drawings update automatically was enough to keep me motivated to make it work. Nick Sonder has proved to many that it is now a very serious option for professionals to consider. I really think that the selling point for many architects would be how easy revisions are, it saves soooooo much time when a client wants to change something in the 11th hour. And they always do. This functionality would just sweeten the pot even more. The more that can be dynamic and automatic the less time you need to spend drafting mindless notations.
yes, this is my thinking exactly
I think leaving existing mechanics “as is” is always preferable unless they are terrible. That way it doesn’t mess up the way other people may be using LO. It seems like the Page ID is a good idea. It would allow direct linking to that page even if the name or order changes. A less preferable option would be to require unique page names and the auto text would recognize any page with that name. If you change the name of the page (rare) you would have to manually update any auto text that was referencing that page name. My vote would be for a Page ID type of system.
I think this would add to what is already a pretty powerful argument for professionals to use the SU and LO system because every architect has been there. You are about to publish the construction documents (or already have) and the client wants to change some things. Show them how quickly and accurately everything updates and you will get some serious interest in learning a whole new system. Because that’s what it comes down to, there has to be some really tasty rewards to entice people to learn a whole new system.
So page references may finally become clickable and export to PDF may support such clickable references. Generated table of document contents may become a sort of navigation menu in that case.
PDF document may become more interactive and easy to navigate by clients. If finally support of interactive orbitable model views inside PDF exported from LayOut will be implemented as well, then it will be a good step to make the whole industry less paper-oriented I think.
The way of implementation of this idea can be similar to implementaion of a hyperlink insertion in presentation software (like OpenOffice Impress for example). Seems like such way became more or less standard so it can be more or less easily understood by users I guess. In this case Page URL attribute can stay invisible for an end user.
Missing links may appear only after page deletion, which is more or less understandable I guess. Changes of Page Name or Page Number or start page should not affect references. That’s the whole idea: link to a page object itself in order to make variable referenced page attributes (like Page Name and Page Number) up to date regardless of any changes.
Right? I’m guessing it’s not just us. I hope some more voices will join this thread and let the developers know that there is some demand for some development in this direction.
Genius, seems so obvious once you say it. It is the right term and people already completely understand what it means.
I love this extension of the idea. How powerful would that be? Sending people a plans with internal links that would bring them where ever they want to go with a click. And having the .PDF table of contents on the left so you don’t have to scroll through pages to go back and forth between a floor plan and an elevation?!?!
I would love to have this just for my own navigation within documents.
I hope so too. As for me I don’t even insist on described implementation or proposed names for properties, I agree that any development in this direction may become useful for LayOut users.
This discussion is intriguing and presents some good ideas. I moved the thread from the “LayOut” category to the more specifically defined category of “LayOut - Feature Requests”. Hopefully other LO enthusiasts will chime in.
I was thinking that it might be appropriate to move it to this category, thank you. Also glad to hear you find the concepts interesting.
Should I edit the first post to include a summary of what has been discussed up until this point so new readers don’t have to read all the posts to learn what the suggested feature would be? I was thinking I would update the LO file I uploaded that provides a visual reference.
