I have a question about how best to manage templates for A4 patent drawings. Patent drawing files may include portrait and/or landscape pages. I’d like to have a template that creates a new (next) canvas that is either in portrait mode or in landscape mode, but I need to have both options available for each new canvas. Simply having one of each orientation in the template (which I can duplicate as needed) doesn’t quite work because it throws off some automated page numbering (e.g.,“FIG. <%#%>”). I suspect that an automation script is probably my best option (perhaps one that pulls the appropriate orientation canvas from a dedicated template file or something in response to a keyboard shortcut), but I thought I would check. Note: I know that I can just drag the appropriate orientation canvas into my active project from an open template containing both orientations, but I am hoping to deploy this to other users who may not feel that is convenient enough for them. 😁
Clarification question. You are right, before you can script something, you have to understand its unscripted operation.
Yes, the template has to have both Portrait & Landscape canvasses, No, I don’t see how that (or dragging a a new canvas into an open file) throws anything off.
-
the page and canvas numbers that matter are in your file (the project)
-
the page and canvas numbers that are in the template are irrelevant (never get published),
- but they must use variables
Use (Menu/Edit/InsertVariable):
- <%CanvasNumber%> <%TotalCanvases%>
Not:
- <%#%> <%TotalPages%>
Hi Guru - Thanks for the quick response! First, I don’t understand the difference between <%CanvasNumber%> <%TotalCanvases%> and <%#%> <%TotalPages%>. They seem to give me the same result, although I will experiment some more and review the OG manual. Maybe the difference, if there is one, will help me! (See option 2 below).
Second, let me try to clarify my question. I apologize for the rambling - I’m finding the background of my particular use case as confusing to explain as what I am trying to accomplish, so it’s difficult to get right to the point.
As a first option, I could simply have a handy template available with both a portrait canvas and landscape canvas. In fact, I already have that and I intend to use the template myself by dragging the right type of canvas from the opened template to my active project.
Unfortunately, I do not believe my colleagues will adopt Omnigraffle as their primary drafting tool with something that feels as kludgey as that. In Visio, they currently open a new project from a template, and it includes portrait and landscape backgrounds that they can apply to new pages. So, to approximate the Visio experience in OG, I was thinking I could script a keyboard shortcut that would “Add a portrait canvas” or “Add a landscape canvas” to an active project (i.e., pull the appropriate canvas from a template in a shared library, hopefully not having to open that template first). Or, I could just script a command to generate a new canvas from scratch with a requested orientation. The latter may be the best choice, but it means I have to (i.e., get to) dig into some non-trivial scripting. (I’m not opposed to that!)
As a second option, which I no longer believe is feasible, I would like to mark the templated canvases as non-pages in some way or at least make some clever use of a template that approximates my users’ Visio experience. Let me provide a little more detail about the current Visio setup. My colleagues are used to using a single Visio template in which I have set up portrait and landscape backgrounds. In Visio, they can select “add a new page” and then select which background (and therefore which page orientation) they want for the next page. Backgrounds in Visio do not get included in the “TotalPages/Canvases” count, so they are “in” the template but they do not throw off the total page count. In this option, every new project can start with the template (see the image I uploaded above), and the users can just duplicate the appropriately-oriented canvas, move it into place in the canvas stack and get to drafting. So, I was hoping to approximate the current Visio experience for my users (i.e., other patent attorneys in my firm) in this manner, without scripting. I no longer believe this is a realistic option (although maybe OG will add it as an option in the future). I’m in communication with OG support humans to fix some bugs in the Visio export functionality, so maybe I can clarify my templating need and ask them to consider adding “background” functionality similar to that in Visio.
In the end, scripting would probably be the more elegant and inviting solution for my users. And, I’d enjoy the scripting experience (although probably not the need to support the script when users complain)!
I hope this makes sense! Thanks again for the response!
Actually, maybe your reference to <%CanvasNumber%> <%TotalCanvases%> and <%#%> <%TotalPages%> triggered a solution! I just reviewed the differences between the two types of variables (i.e., pages and canvases). Pages are canvases that are configured to be printable. That suggests that I could turn OFF printing of the template canvases and they will NOT be included in the <%#%> <%TotalPages%>. I will see if this will work! Thanks!
You are most welcome.
Good. I am opposed to that which is non-trivial, especially if it is not necessary.
- I don’t see why this problem needs a script, and
- the script you are describing will have nasty problems due to Template location and determination.
Why don’t you:
- place the Template file in a shared library, ReadOnly
- let them, instead of OpenNew and drag-from Template, File/TemplateChooser, and select the Template for the [implied] new document.
Well, teach them that the “background” fixation is a Visio::OG step mismatch problem, and just to open a new document from a Template. Forget about backgrounds.
That is not quite correct…
Before you figure out the difference in the Variables, you need to understand what the thing that the Variable refers to, means.
- Page and Canvas are not defined in the manuals. (They are great-looking marketing organs.)
- Page does not equal Canvas.
- First, get notion of Visio “background” out of your mind.
- (It appears to me that it is a thing that OG V4 had, that has been removed in post-V4 releases. Some of its facility can be implemented in a Canvas, some of it has to be implemented in multiple SharedLayers (whereas in V4 and Visio it is in a single thing). In any case, for this discussion, let’s use OG terminology.)
Canvas
A Canvas is the thing you draw a single or multiple diagrams on.
- It is the first Unit of Measure in OG.
- Same as a Sheet in Numbers: you can have multiple objects (tables; charts; graphs; text boxes) on a single Sheet/Canvas.
- The simplest OG document (file) is a single Canvas.
- A Canvas is the single thing that is displayed in the main window of an OG document (file, that you work with).
- To begin with, a Canvas has no relation to a Page or to printing.
- Mess around with the objects, get them looking exactly the way you want.
- Same as with Numbers, you can select a drawing or a chart or a group of objects, Copy it, and Paste it into another document (eg.) Pages; or as an image in a web page; etc.
- For organisational purposes, if you have several related diagrams, or several diagrams of different types in a single Document, you may place each of them on a separate Canvas.
- If you do use headers and footers for the Canvas, the Variables will therefore be
<%CanvasNumber%> <%TotalCanvases%>.
No mention of Page or Page items thus far.
Canvas Size
It can be anything you want.
- But it does get silly when you consider that it is 2018 and each country uses fixed sizes for many reasons, which have been elevated to an external Standard, and which most people know and understand, which exist for the purpose of easing communication and avoiding problems when documents (files) are exchanged.
- Eg. US Letter in American colonies vs A4 in the Rest of the World.
- Further, the understanding is complicated (as distinct from silly) when the features of OG such as Auto-sizeCanvas; FitToSize; Pickle&Oil; etc, are brought in. Therefore let’s exclude those marvellous features until understanding has been achieved, and bring them in if and when it has.
Therefore, for a reasonable person, for most drawing tasks, the CanvasSize will be:
- set using the second OG Unit of Measure: PageSize.
- And of course, we use Standard PageSizes, rather than custom sizes for each canvas (which an unreasonable person would use)
- A Canvas is therefore a multiple of a PageSize.
- PageSize; Orientation; and Scale, are set at the Document (File) level, via File/PageSetup
- Orientation only (not PageSize & Scale) can also be set up at the Canvas level - which is where your problem is focussed
- In older releases of OG, Scale can be set at the Canvas level. The removal of which is badly missed.
- Note that Orientation is an attribute of a Page, not of a Canvas. Yes, of course, since the Canvas is a multiple of PageSize, the Canvas indirectly has one Orientation.
That allows you to draw diagrams of any reasonable size, and to use the objects or object groups or the diagram as a whole, in other documents. One can produce PDF files and exchange them with other people, to facilitate communication of complex things, such as project plans; data models; architectural plans; etc. For decades, I have communicated complex articles in the form of PDF files, without having to print them (this is not to exclude the need for printing, which I will deal with in the proper order).
Still no mention of the Variables related to Page <%#%> <%TotalPages%>, or the hard-and-fast limitations of a Page or PageSize.
Template
In order to save time in document set up, and to obtain Canvasses that have a consistent format, with or without initial objects, a Template can be created. Further, a Template can be shared, simply by placing it on a shared folder somewhere in the corporate network, usually a shared library.
Since a document is first a Canvas, and a Canvas is second a Page & PageSize, and that is set at the document level, a single Template would be for a single Canvas set up, which is a PageSize.
- Eg. for my architectural drawings, which have a corporate logo; a legend; a header; a footer,
- in terms of content, I have one Template,
- but a Template File for each PageSize: A4; A3; A2; A1; A0; and US Letter; 11x17; 17x22,
- with two Canvasses, one for each Orientation: Portrait and Landscape
- All that is set up using the fewest Shared Layers, carefully. Such that the draftsman can simply, for each new (2nd and subsequent) Canvas, if not the same as the first:
- set the PageOrientation (not PagesSize) and
- drag in the SharedLayer that is required.
- Compared with the MasterCanvas in older releases, the SharedLayer is
- a royal pain (duplication and far more manual labour), but hey, that is “progress” in OG terms.
- So the number of Layers in each Canvas in each Template in a post-V4 OG document is far greater than in V4, and requires the Template user to mess around much more.
- This needs to be mentioned, because the Visio “background” and its ease-of-use is equivalent to the V4 MasterCanvas, which is lost. Do not look for it. Expect to implement its work via multiple SharedLayers.
A minimal Template would therefore pertain to one PageSize, with two Canvases, one each for Portrait and Landscape. Same as a Numbers or Pages Template.
Again, simple if Standard PageSizes are used. A Template for custom sizes, or for Auto-size, would be very silly, because its usefulness is limited to content, not Canvas format.
Still no mention of the Variables related to Page <%#%> <%TotalPages%>, or the hard-and-fast limitations of a Page or PageSize.
Printing
There are of course, projects that require the Canvases to be printed, a PDF flashing up on a screen is simply inadequate. Something that is visible as a result of contemplating the whole diagram on a single page that is stuck on a wall or window, is lost when viewed through a [much smaller] screen, which is really a fixed window into the Canvas.
Printing requires a device called a Printer, and such devices take Standard PageSizes only. Printers that use large PaperSizes cost large sums of money.
By way of explanation of the considerations, let me identify the way I work. Obviously, other people will have different needs and considerations, but this nevertheless explains that which needs to be understood.
- These days, most customers have a good colour printer, but it is limited to A4 or A3. Some printers are laser, which is high quality and resistant to fading, but most are ink-jet, which has poor resolution and fades quickly. High quality paper is also far more expensive than low quality paper.
- In a given project, I may have a data model that is drawn on an A2 Canvas. When I get close to the final draft, I go to a print shop and print it in vivid colour, on a laser printer, on A2 paper. Although that costs only a few bucks, I don’t run off to the print shop every second day if I can help it.
- For presentation and discussion purposes, I print that A2 Canvas in A1.
- For everything up to, and excluding close-to-final draft, the A2 PDF viewed on monitors (ie. not printed) is quite adequate.
Still no mention of the Variables related to Page <%#%> <%TotalPages%>, or the hard-and-fast limitations of a Page or PageSize.
PageSize Limitation
Whereas I produce a high-quality (eg.) A2 printed page at the the close-to-final draft stage, for all projects, for some projects, before the close-to-final draft stage, ie. the duration of the modelling exercise, I need to print interim versions of the model, which uses the nasty corporate printer, that is limited to A3.
- Of course, I can print an A2 Canvas on A3 paper. But such a diagram would be too compressed to read, due to the scaling down (while remaining quite pretty to gawk at).
- I need it at full scale, for reading.
- It is no big deal to draw the A2 model such that it can be printed on 2 x A3 pages: just keep complex objects out of the middle of the diagram (the page split area), and ensure that the fewest lines go through it.
A. Not Perfect
For those projects (and yet other projects the reader here may have), we need such pages numbered, and with a consistent footer. Eg. I have one customer whose developers are so stupid, they need a fresh copy of the data model every time I make the slightest change. They can’t wait for a few changes to be batched up, and a single high-quality A2 page to be printed at the print shop. For them, I perform the following:
- Create a little Page Footer object with a Line; and document and page info
- Include the <%#%> <%TotalPages%> Variables
- Create a new SharedLayer A3 PageFooter (as distinct from my A2 CanvasFooter SharedLayer)
- In the A3 PageFooter SharedLayer, duplicate the PageFooter object and position it at the bottom of each Page. Note”
- the SharedLayer (both A3 PageFooter and A2 CanvasFooter) pertains to the Canvas Size because that is the diagram size
- the A2 CanvasFooter SharedLayer is intended for A2 printing, it has one Canvas footer object
- the A3 PageFooter SharedLayer is intended for A3 printing, it has one Page footer object per Page
- Turn the A2 CanvasFooter Layer Off
- Turn the A3 PageFooter Layer On
- Print the bastard child in its fragmented pieces
- Note that “CanvasSize does not equal PageSize”, assembly is required
- If they drop the fragments, they can re-assemble the whole via the Page numbers.
Such Pages work quite well, as long as the reader is not unreasonable, assembling the Pages into a single Canvas is easy. Leave it as is for viewing on a table, or use a bit of Scotch tape for hanging.
B. Perfect
That is acceptable for that sort of circumstance, but not for others. Where a perfect print of a Pages-not-Canvas document is required for a customer (rather than for his development boffins), the requirement is different again. My data model is still A2, but the final draft on A3 is required.
- Now the PageSize for the OG document is A2, and it remains so throughout the life of the model (it may grow, but it will not shrink).
- When preparing for the [perfect] print task, duplicate the document (I add a suffix “Print”). This document exists for the duration of the print task only.
- If the Orientation in A2 is Portrait, it will be 2 x A3 Landscape, top and bottom. If in A2 it is Landscape, it will be 2 x A3 Portrait, left and right.
- Change the File/PageSetup/PageSize from A2 to A3
- Turn the A2 CanvasFooterPortrait Layer Off
- Turn the A3 CanvasFooterLandscape Layer On
- The first Page (top half) is fine. The top half of the diagram is visible, and the bottom half bleeds off the Canvas. Yes, Canvas.
Note that now “CanvasSize equals PageSize”.
- But if this (discard copy of the document, for the sole purpose of printing, and set up for such, and existing only for the duration of such) were the only lens through which one were to view and understand an OG Canvas, it would be severe limitation indeed, to both the approach and the use of OG as a drawing tool.
- Worse still if one set up one’s Templates with only that way of viewing and drawing a diagram [that has consistency in Form, from the use of a Template].
For the second Page (bottom half of the diagram), we have a bit of work to do:
- Duplicate the Canvas, to obtain Page 2 (Canvas 2)
- Group the entire diagram into a single object. That will collapse object distribution across multiple Layers into one, but we don’t care, it is a discard copy.
- If you use a Grid (and you should, always), set the Canvas/Grid/MajorSpacing to 8 or 16 times what it is. This is for convenience in the next step
- Shift the diagram (now a single object) down one Page. This will be easier with a large Canvas/Grid/MajorSpacing setting
- Ensure the bits that bleed off the Pages (bottom of Page 1; top of Page 2) line up perfectly. Again, easy if you use a grid
- Export to PDF and send to the print shop.
In the same way, an A1 diagram can be printed on 4 x A3 pages, etc. But the work required for the 2nd and subsequent Pages (steps above) is onerous. Prohibitive, if you have to do it often.
Finally
Of course, others will have different requirements, and the need for printing Pages rather than Canvasses more frequently. However, in all cases, all the above needs to be taken into account, and in the declared order. Many people get confused or falsely think OG is limited in some way, because they reverse the order required for a good and proper understanding.
Once you have that understanding, the OG Features such as Auto-sizeCanvas and SizeToFit can be contemplated. Reversing the order is incorrect because it is not possible to grasp the relevance of a complex feature, or to use it reasonably, before one has obtained a full purchase on the simple feature operation.
- Just check the many posts that inquire about these features “Why can’t I get Auto-size to work … [the way I think it should] [without understanding how non-auto-size works]”
- It is like trying to ride a motorcycle without ever having learned to ride a bicycle, and having skinned one’s knees, which demonstrates the acute awareness of both balance, and the point at which one loses it, which is demanded for riding a motorcycle.
As you can see, a little ‘thank you’ reaps rewards.
Cheers
Please note that as of 02:00 Australian Eastern Standard time, I have
- added a section, and
- improved the clarity throughout.
In any case, the post is intense, a second reading will not hurt.
Cheers
Hi Guru - Thanks again for the in-depth guidance! Your explanation of Canvases and Pages really clarifies (i.e., corrects the manuals sparse contribution).
I read your initial post this morning, even before my first cup of coffee, and it made sense to me. Your revised effort is even better, and I have saved it in my document repository for future reference.
Although this is my first substantive post in the OmniGraffle forum, I have found your responses extremely helpful! It doesn’t seem like a very busy forum, but perhaps that will change in the future. E.g., if Omni can fix the Visio export functionality, a lot of patent attorneys would start using OG over Visio (albeit, that’s not the largest demographic in the World).
Thanks again! I will report in the future on my experience with attempting to get OG adoption in my firm.
Thank you for your kind words. You are most welcome.
In that case, gee, I will have to pay more attention to the Form (structure) of my answers !
Unfortunately, no.
In the old days, the first decade, when OG 4 rocked the Mac world, and the competition was miles behind, we had a normal forum. Normal in the sense of what is expected from a forum: a high degree of technical and product knowledge; truth, without reference to marketing; conservative but incisive participation by the development team, all of which sustained a massive amount of user participation. OG 4 was king, GraffleTopia was queen, and the forum was the knights.
But the product management changed drastically, and dev team changed, actually twice. The product now looks and feels sexy, but it has had some important features removed, and it is full of bugs.
GraffleTopia with 1,100 serious Stencils; hundreds of thousands of downloads (mine alone are 46,000), is suppressed, and StencilTown with 380 “stencils”; that look great but are inadequate as Stencils; mostly duplicated; downloads unknown, is elevated.
The forum has been archived (suppressed), replaced with this new “forum”, which is a de facto marketing tool, replete with censorship of truth that might sound negative re the product or truth that is deemed to hurt the feelings of snowflakes. This does not foster either serious participation or truth. The questions and answers are likewise superficial and low value (with a few notable exceptions). For the last month, there has been no development team participation.
What you see as my participation is actually severely curtailed, because my posts are deleted. I am not going to spend time writing up serious solutions to serious problems, when such posts routinely get deleted. There was a time when the dev team asked us to identify what features OG 4 had, that OG 7 removed, that we want re-instated, but it was all for show, as those posts have been deleted. I posted four serious items out of twelve, and then stopped.
Depending on the feature set being compared, the competition are now either on OG’s heels, or miles ahead. Superficial new features and requests get implemented, while the core feature set deteriorates and keeps getting trimmed. Compared with V4, which is a robust commercial product, and fully tested, the current version demands testing by the customer base. We pay to test every minor product release, which is often, while never achieving robust or commercial status.
Compared with the V4 dev team, who provided great support, current support is virtually non-existent, but they do solicit new feature requests.
Last but not least, the price. V4 Pro was $50. V7 with a reduced core feature set; with tons more superficial features and bugs; untested, is $200.
That is a narrow way of perceiving the problem. What we need is full import/export from/to existing Standards, not from/to existing products. All parties, the dev team as well as users on both sides of the Mac/Widows fence, will have far less work each and every time they transfer a drawing.
After seeing my diagrams (ie. the content, not the tool), it often happens that a customer will ask me to improve or upgrade one of their existing Visio diagrams, outside the project.
-
I use OG exclusively, I need only the import from Visio, just to obtain the objects and placement as a starting point (I don’t actually use the Visio objects, I use Standard symbols exclusively), and it used to be easy. Long gone, now I have to mess with the import as well as fix-up all the connecting lines.
-
Many people need SVG export to replace the obsolete HTML export. But it sucks dead bears, so I am forced to stay with the obsolete but working HTML export.
But hey, new superficial features are coming out monthly.
Cheers
Ouch! I hope things are not as dire as you make them sound. Otherwise, I’ll have to go to Illustrator or something like that! OG is far better than Visio, which hasn’t gotten much TLC in recent years. Perhaps this is the state of vector programs these days, but OG certainly is a better tool. Nevertheless, in my industry, certain clients require Visio output, so I am stuck with this. Unless I want to continue to struggle with the limitations of Visio, my best hope is to find clients who are happy with PDF output and get an accurate export to Visio when necessary. I will also try to make my own contributions to this forum and work with Omni Support on the Visio export issues. They seem interested in fixing them so far.
Thanks again for all your help! I hope I can post another query interesting enough for you to respond, as I have enjoyed your outstanding responses - I have already learned so much that is not very clear in the manual. I really appreciate your help!
You are most welcome. It is a relief to deal with straight-talking people. Very few have the courtesy to leave a thank-you note, yours is likewise very much appreciated.
The manual is written for children. It does not read like, it is not structured as, a serious product manual. Worst, people don’t need to be told, under the heading of How to perform a Fubar, "just go to Fubar dialogue and press the Fubar button. Any idiot can figure that out (once they find it in the anti-intuitive GUI). What we need is, a definition of Fubar, and what its limitations are, As you have stated, the content of my post in this thread should be in the manual (properly structured of course).
Yes.
I have been evaluating the competition for a few months. There is a fair amount of turn-over in this space (Vector drawing tools, one notch below AutoCAD). In the past, as evidenced, the team within OG has suffered total replacement, several times. This time (note the dev team’s silence in the last month) it is either happening yet again, or OG itself will cease its existence. So while there is a fair amount of good competition to choose from, and at a fraction of the OG price, making the product choice fairly straight-forward, the evaluation of their long-term corporate viability will take a bit longer.
Cheers
