I would like to have the grid limited to the size of the paper on which the diagram is to be printed. The outer bounds would possibly be made off limits but the grid would limit the print bounds.
Possible?
What are the ramifications?
Can you point me to some knowledge?
Hi - you pose an interesting question that I would be keen to know the answer to. I’ve looked at modelling physical-world paper in virtual space on a PC before now and there were always considerations of device pixel density to take in to account. In the olden days of steam power you could work with 72 dots per inch on a PC monitor and do the math to work out your on-screen dimensions from that. Then monitors got better and moved to 96dpi. And now we have very high dot density screens on iPads and iMacs, etc. Long story short, you will need to know the viewing device dot-density if you want to produce the paper actual-size on screen.
That is quite a tricky approach so what you might want to do is a trade-off and provide an on-screen paper size that ‘feels’ like it represents a reasonable real-world size when the diagram is printed.
Regardless of the approach, once you have the dimensions, you could have 2 diagrams overlapping and pinned to the same origin. The ‘lower’ one would be fixed at the paper dimensions and would display the grid. The ‘higher’ one would be where your diagram nodes go, and would have a transparent background.
What do the uberlords at Northwoods suggest ?
The first issue that might not be clear to everyone is that a “Grid” Panel can be used as a regular Panel. It need not only be used as the value of Diagram.grid, in which case it serves as the pattern for the infinite grid that the Diagram draws. We should improve the discussion at GoJS Grid Patterns -- Northwoods Software to cover what ought to be obvious but isn’t.
The second issue involves a limitation on dragging to a particular area. The DraggingTool normally limits dragging of Parts (including Nodes) by the values of Part.minLocation and Part.maxLocation.
But more generally it is Part.dragComputation that allows a programmer to limit the user’s drags in an arbitrary manner. You may already have seen the stayInGroup function in the Swim Lanes sample. But the stayInViewport function given by the Part.dragComputation functional property is what you want to adapt for your own purposes. Instead of using the Diagram.viewportBounds, you’ll want to use the bounds of the “sheet of paper” object.
The third issue is the “sheet of paper” object itself. I suggest that you create a single Part that is in the “Grid” Layer and that is sized and positioned by you to represent a sheet of paper. Read GoJS Legends and Titles -- Northwoods Software about such Parts. It is your choice whether you want the “sheet of paper” object to be in your model or not – I don’t know what your app requires.
The fourth issue involves what @JEE just mentioned – determining the correct size in document coordinates for the “sheet of paper” object. It is basically impossible to make sure that the rendering of any rectangle, whether in Canvas or SVG or just as an HTML element, is actually a particular physical size. It is just too easy for users to change the scale of the display or to change the zoom level of a window/page or to project onto a wall screen. And even when only considering printing, there are too many printing options that the user can choose that will affect the actual rendered size – sheet size, zoom levels, multiple pages per sheet, and who knows what other options that the chosen printer supports. Furthermore access to many such properties that is available to native applications is not available to HTML/CSS/DOM/JavaScript.
So I would be extremely wary about trying to provide a faithful rendition in HTML of the sheet of paper and the diagram contents that might be printed.