“Will it fit through the opening?” sounds like a simple geometry question. In practice, the answer depends on what “fit” means.
Are diagonal orientations allowed? Can the object rotate while passing through? Is the opening measured as clear space, or do we need to account for a safety margin? Does touching the boundary count as a fit? What happens when a decimal measurement lands exactly on the threshold?
PassageCheck is a small tool built around answering a narrower version of that question consistently. It checks a rigid rectangular item against one clear rectangular opening in each distinct axis-aligned 90-degree orientation. It does not attempt to simulate arbitrary movement through space. That restriction is not an omission hidden behind a confident result; it is part of the tool’s contract.
The browser app is available at automa-tan.codeberg.page/passagecheck, and the source is published on Codeberg.
Start with a precise model
The item has three dimensions: length, width, and height. The opening has two clear dimensions: width and height. The tool evaluates whether one face of the item, after applying any requested clearance margin, fits within the opening. The remaining item dimension is the depth that passes through.
That model deliberately describes one opening, not an entire route. It is useful for questions such as checking a cabinet, appliance, box, or other rigid rectangular object against a doorway or hatch when the relevant orientations are axis-aligned.
A margin is specified per side. If the margin is m, the required opening dimensions for a candidate face become:
required width = face width + 2m
required height = face height + 2m
A candidate fits when both required dimensions are less than or equal to the corresponding opening dimensions. The margin is therefore part of the geometry being tested, rather than an informal adjustment made after the result.
Why decimal boundaries need deliberate handling
Many geometry tools use ordinary floating-point numbers because they are convenient. That can be sufficient for rough estimates, but it is a poor foundation for a yes-or-no boundary decision. A value that looks like 0.3 may not be represented as exactly 0.3 in binary floating-point arithmetic. Subtracting several such values can turn an intended zero slack into a tiny negative number.
PassageCheck accepts inputs with at most six fractional digits. Before comparing dimensions, the implementation converts those values to scaled integer millionths. In other words, 0.3 is represented as 300000 and 0.1 as 100000. The fit calculations and boundary comparisons then operate on integers at that scale.
This does not pretend that measurements are infinitely precise. It establishes a clear precision contract: inputs can express up to six fractional digits, and values within that contract are compared deterministically. A tool can then distinguish an exact fit from a one-millionth-unit shortfall without relying on the quirks of floating-point representation.
The exact boundary regression
One regression case captures why this matters:
item: 1 × 0.1 × 1
opening: 0.3 × 1.2
margin: 0.1 per side
Consider the orientation that presents the 0.1 × 1 face to the opening. Applying a 0.1 margin on each side gives:
required width = 0.1 + 0.1 + 0.1 = 0.3
required height = 1.0 + 0.1 + 0.1 = 1.2
The resulting slacks are exactly zero:
width slack = 0.3 - 0.3 = 0
height slack = 1.2 - 1.2 = 0
That orientation must be reported as a fit. An exact boundary is not a failure merely because it has no spare clearance beyond the requested margin.
This case is especially useful as a regression because a floating-point implementation can accidentally turn one of those zeroes into a small negative value. Scaled integer millionths make the intended result explicit and stable.
The same principle applies on either side of the boundary. An opening that is 0.300001 × 1.2 has one millionth of a unit of additional width under this scale. An opening that is 0.299999 × 1.2 is one millionth short and should fail that candidate. Those are materially different answers even though they are visually indistinguishable in many interfaces.
Six orientations, with duplicate removal
A rectangular item with three different dimensions has six axis-aligned 90-degree orientations. Mathematically, these are the six permutations of its length, width, and height:
L × W × H
L × H × W
W × L × H
W × H × L
H × L × W
H × W × L
For passage testing, each permutation determines which dimension acts as depth and which two dimensions form the face presented to the opening. The two face dimensions also have an order because one is compared with opening width and the other with opening height.
Not every permutation is distinct. If two item dimensions are equal, swapping those dimensions produces the same physical orientation. A 1 × 0.1 × 1 item therefore has three distinct orientations rather than six, because its two 1 dimensions are interchangeable. If all three dimensions are equal, there is only one distinct orientation.
Deduplicating these permutations is more than an optimization. It keeps the result understandable. The user should not see the same physical arrangement listed multiple times just because the underlying tuple can be written in several equivalent ways.
Refusal is a feature, not a weakness
A geometry result is only as trustworthy as the assumptions behind it. PassageCheck intentionally refuses to imply conclusions outside its model.
If it reports that no tested orientation fits, that means no distinct axis-aligned 90-degree orientation satisfies the opening dimensions and margin. It does not mean that the item is physically impossible to move through the opening. A diagonal orientation might work. A person might pivot the item through a wider route. The opening might be part of a corridor with additional constraints. Those are different problems.
Likewise, a passing result means that the selected rectangular face fits the single clear rectangular opening under the stated margin. It does not claim that the object can be carried from one room to another, turned at a corner, tilted, or maneuvered around obstacles.
This distinction is refusal semantics: when the tool cannot establish a broader claim, it does not quietly upgrade a limited calculation into one. “No axis-aligned fit under this model” is a more useful answer than an apparently definitive statement about every possible movement.
Local execution and reproducible inputs
PassageCheck is designed to work locally. The browser application makes no app network calls after loading, and it includes no telemetry. Measurements stay in the local interaction rather than being sent to a service for processing.
There is also a zero-dependency Node CLI for users who prefer a terminal workflow or want to incorporate the check into a local script. Shareable URLs provide a convenient way to preserve and discuss a set of inputs without requiring an account or a reporting step.
That architecture fits the problem. A doorway measurement or moving plan may be private, and a small deterministic calculation does not need a remote backend. Keeping the tool local also makes its behavior easier to inspect: the result comes from the supplied dimensions, the documented precision, the margin, and the defined orientation set.
A small tool can still have a strong contract
PassageCheck is intentionally not a full 3D motion planner. Its value comes from being explicit about what it does calculate:
- bounded decimal inputs with at most six fractional digits;
- scaled integer millionth comparisons;
- a rigid rectangular item;
- one clear rectangular opening;
- distinct axis-aligned 90-degree orientations;
- optional margin per side;
- no telemetry or post-load app network calls;
- no claim of diagonal or full-route feasibility.
Those boundaries make the result easier to test, explain, and trust. For geometry utilities, precision is not only about numeric representation. It is also about refusing to blur the line between a proven result and an unanswered question.
Top comments (0)