Paper Space II

In the last installment about paper space I discussed a desire for the paper to be automatically handled, and for the documents to automatically be scaled and sized. That post landed on one rule for one view on one sheet: scale and orientation are outputs, not settings. The app picks the largest scale that fits, and the north arrow and the site geometry decide landscape or portrait. That solves one drawing, which is the easy part. A set is many views of one model, and the model keeps changing. The question here is what has to stay put when it does, and what has to move.

Using my experience at TestFit I know that generating PDFs is quite important to customers, but why stop at PDFs, when you can do a more generic paper configurator, snap a view of the model with its current view conditions (like 2D views of topo with the building being zero opacity or dashed in above geometry) and saving that view for continuous future use.

A view condition is everything about a view except the model: which layers are on, how the building is drawn, which discipline it belongs to. That is the part worth saving. The geometry is the part you should never save twice.

Working with UI/UX Designer Michelle Wern we hijacked the BALOS and used that for more of a sheetset generator, along with a new idea of “creating a sheet from the current view”. Since views can change their scale all over the place (in future drawing sets) it needs to be a dynamic setting.

Look at the sheet list in that mockup: eighteen sheets, every one at 1″=100′. That’s the placeholder telling on itself: a scale typed into a column once and never recomputed.

So here is the one distinction a sheetset has to get right. Some things belong to the view (or its sheet) and should never move when the model does: topo on or off, building solid or dashed, discipline, title block. Other things belong to the model and must move with it: the geometry, project north, and therefore the scale. Project north is the rotation that squares the building to the sheet instead of following true north. TestFit had shipped Project North that January, rotating the 2D view to a site plan orientation for exports, so the orientation already existed.

I also think the idea that the entire sheetset can re-evaluate its scale based upon project north and a change in current geometry (like exporting a main plan and not just one site) is controlled for.

Four saved views, four states of the model

The drawing above runs that argument on four saved views of one building: a site plan, the same plan with topo on and the building dashed at 24%, a north elevation and a section. Each sits on a landscape Tabloid sheet, 17″ × 11″; after a ½″ border and a 1½″ title strip, the printable area is 16″ × 8½″. The scales are ratios of paper to building: 1:48 is ¼″ = 1′, 1:96 is ⅛″ = 1′, 1:192 is 1/16″ = 1′ and 1:384 is 1/32″ = 1′. (The mockup’s 1″=100′ would be 1:1,200.) Sizes below are printed width × height.

The saved conditions are identical in every row; only the scales move. Row 1 is why scale can’t be a column: pinned at 1:48, the plan wants 30″ of a 16″ printable width, and none of the four views fits.

Row 4 is the lesson. This drawing holds the plans to project north and keeps every sheet landscape, so after the 90° turn the 200′ side has to run up the 8½″ printable height. At 1:192 it would print 12½″ tall and clip, so the set falls a full standard step to 1:384. Compare the last row: with north left at 0°, the same plans fit at 1:192. Turning the north arrow cost them half their printed size.

There are two ways to get 1:192 back, and only one keeps north. Spin the drawing on the sheet and the plan fits, but project north is gone. Stand the sheet up as portrait instead and the printable area becomes 10″ × 14½″: the 12½″ plan fits at 1:192 with north intact. That is TestFit’s rule from Part I, orientation as an output; this drawing deliberately holds the sheet landscape to show what happens without it. Scale, sheet orientation and north are one decision. Solve them as three settings and the set breaks exactly when the model changes, which is exactly when someone is about to print it. Solve them together and the worst case is a smaller drawing, not a broken one.

Lastly, it is hard for me to visualize how a user might add several images easily, and continuously from pre-existing settings. Perhaps we do create 8-16 default views, present a way of viewing those on a pdf altogether or individual sheets. Since PDF is an unlimited resource, MVP of one image per sheet is okay. The other out of the box analysis that we include in app would need their own formatting systems if we upgrade PDF further. I hope our web enabled collaboration is more powerful of a central data hub, but I think we only get there if the data hub can generate all of these drawings and documents on the fly anywhere, anytime. PDF is coming for the cloud.

My judgment: coordination is not a feature you bolt onto a sheetset; it is the only reason to have one. Save the conditions, derive the scale, and hang every view off one model and one north. A set that stores pictures is a folder of screenshots that goes stale the first time the building grows. It is also why Part I’s report can consolidate self-similar views like typical floors: when every view hangs off one model, the set can tell two sheets are the same drawing and print it once.