Skip to main content

window — the opening that brings in light

boundary /pathA /pathB …
  window [AssetName] w:1650 h:1100 [at:…] [edge:…] [hinge:…] [swing:…] [style:…] [panels:…] [name:…] [sill:…]

A window is written one level of indentation under a boundary. How its position is written — the ratio and grid-reference forms of at, choosing a side with edge — follows exactly the same rules as a door.

Two things differ. A window is not passable, so it adds no edge to the graph koyu doors walks; a wall with nothing but windows is still a wall you cannot get through. And a window counts toward daylight.

Write both w and h​

AttributeRequiredMeaning
wyeswidth in mm along the segment. A referenced asset may supply it
hoptional for form / required for daylightheight in mm

Without w, parse stops. Without h, check still comes back green — but the window drops out of the daylight count entirely, because window area is the sum of w × h over the windows that have an h.

muro 1.6
name 窓の書き方
unit mm

grid X 0 6000
grid Y 0 4000
level L1 0 h:2700 slab:200

space /L1/a room X1..X2 Y1..Y2 name:居室 daylight:1
space /out name:外部 outside:1

boundary /L1/a /out t:150 edge:S
  window w:1650 h:1100 sill:900 name:腰窓
boundary /L1/a /out t:150 edge:N
  window w:2600 h:2200 name:掃き出し窓
boundary /L1/a /out t:150 edge:E
  door w:900 h:2100 name:出口
boundary /L1/a /out t:150 edge:W
  /L1/a	居室	window 7.54 m2 / floor 24.00 m2 = 1/3.2

Drop h:1100 from the low window and the number falls from 7.54 to 5.72.

  /L1/a	居室	window 5.72 m2 / floor 24.00 m2 = 1/4.2 ⚠ windows without h: are not counted

koyu check stays green. What puts it into words is validation, under the rule koyu.schematic.daylight.unknown (caution).

⚠ [koyu.schematic.daylight.unknown] win.muro:line 9: Window area is not fully counted: /L1/a has a window without h: (write h: on it)

It does not say "there is not enough window"; it says "the count is not complete". The report is that the source does not carry enough to answer the question either way.

Sill height is not written — it is what aligning the head leaves behind​

The head of an opening sits at the lintel height of 2000mm. A door rises from the floor to meet it; every other opening drops from it by its own height.

Writtenz range of the opening (above FL)
window w:1650 h:1100900 … 2000
window w:2600 h:2200−200 … 2000
window w:1650 (no h)800 … 2000 (default height 1200)

The 900mm sill on the first line is written nowhere. It is what 2000 − 1100 leaves. And as the second line shows, take h above the lintel height and the bottom of the opening falls below the floor. If you want a full-height window, choose h knowing that the difference from the lintel height is what does the work.

sill: is a carried attribute — it is in the ledger, but the core never reads it once. Write it and it travels into the canonical JSON for another tool to use. It moves no geometry. Change sill:900 to sill:400 in the example above and the window still runs 900 … 2000.

style — the window plan presentation​

Every window keeps the same base mark in plan: the wall's two face lines continue through the opening, unfilled. They are not joined at the jambs and there is no glazing centre line. The operation is added over that frame.

WrittenWhat is added to the frame
no style:nothing — a general window
fixeda short fixed-window centre mark
slidingone sliding sash and its storage guide
sliding-doubletwo sashes meeting at the centre, with guides to both sides
sliding-bypasstwo overlapping sashes
hingedone leaf and its swing arc
hinged-doubletwo equal leaves and their swing arcs
projectingthe projecting sash and its two returns
curtain-wallthin divisions at the explicitly written equal panel boundaries

hinge: names the jamb or storage side and swing: names the side on which the operation is shown, by the same rules as a door. No style is inferred from the window name, width or asset identifier.

Curtain walls keep schematic detail schematic​

asset CW4 window w:6400 h:2600 style:curtain-wall panels:4 name:Curtain-wall-four-panel

A curtain wall keeps the same two unfilled face lines as every window and adds one thin transverse line at each interior panel boundary. The example has four equal panels and therefore three marks. The marks state facade division at general-plan scale; they do not reproduce a manufacturer's mullion profile.

panels: is source data. No count or pitch is inferred from the width, name or asset identifier. Omitted, it is one, so no interior division is added. The value must be a positive whole number and may be written only on a window with style:curtain-wall; otherwise OPN10 is an error. An asset is the usual place to keep a repeated facade type's width, height, style and panel count together.

A four-panel curtain wall in a schematic plan

Automatic-door, entrance, gate, shutter, overhead and unequal hinged operations are door-only. Writing one on a window is OPN09 (error). A word outside the complete opening-presentation vocabulary is ATT02 instead.

The daylight coefficient​

light looks only at spaces with a region that carry daylight:1. Nothing is inferred from the type — write room or write bedroom, and without the declaration the space is out of scope.

Effective window area is discounted by what lies beyond the window.

What the window facesCoefficient
the outside (outside:1)1.0
semi-outdoor with a space above it (under a balcony, under an eave)0.7
semi-outdoor open to the sky (a garden, a top-floor balcony)1.0
anything else (indoors to indoors)0 — not counted

Whether a space is semi-outdoor, and whether it is covered from above, are both derived rather than declared. A space with a region that meets the outside across an open or air:1 boundary is semi-outdoor.

The judgement itself — effective window area ≥ floor area ÷ 7 — is passed by koyu validate under koyu.schematic.daylight.ratio (violation), not by check. It is a rough early warning with no correction factor applied, and it looks at neither use-class proportions nor which buildings the rule applies to. Where the 1/7 lands is decided by the author, in choosing where to write daylight:1.

Attribute tiers​

AttributeTier
w h at edge hinge swingstructure
style panels nameinterpreted
sill spec firecarried

A window uses the same ledger as a door. hinge, swing and style may all be written. Hinged window styles draw their arcs, but a window remains impassable regardless of what is drawn. A key outside the ledger needs a namespace containing a dot (acme.glazing:low-e) or it is ATT03.

Diagnostics​

The diagnostics are shared with the door: OPN01 through OPN10, VRT05, UID04. OPN03 (an opening on an open boundary) says the same thing it says for a door — no effect on passage — which for a window was never in question.

To look a code up by cause and cure, there is the list of diagnostic codes.

Neighbouring pages​

  • boundary — the relation a window sits on
  • door — same rules for position; only this one is passable
  • asset — putting the defaults of a window in one place
  • koyu light — returns the daylight numbers
  • koyu validate — passes the 1/7 judgement