Repository navigation
Conversation
A clipped block reference shows only what is inside its SPATIAL_FILTER boundary, and AutoCAD measures the drawing's extents from what survives the clip. GetBoundingBox returned the whole block, so a clipped insert claimed ground the drawing does not occupy. The boundary is now intersected with the block's box before the insert transform is applied. An empty intersection is left alone rather than trusted. One detail worth flagging: both DWG and DXF record InverseInsertTransform as three rows of four with the translation in the fourth column, and the readers store it exactly so - while Matrix4's own multiplication reads the translation from the fourth ROW. Applied as stored the matrix silently drops its translation, which for a clip boundary is the whole of what it carries, so it is transposed at the point of use. Nothing else in the library consumes these two matrices, which is presumably why the mismatch has gone unnoticed; normalising them at read and write time would be the tidier fix and is left as a separate question. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Aug 30, 2026
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The problem
A clipped block reference shows only what falls inside its
SPATIAL_FILTERboundary, and AutoCAD measures the drawing's extents from what survives the clip.Insert.GetBoundingBox()returned the whole block, so a clipped insert claimed ground the drawing does not occupy.Measured on a drawing where the block
he cot chuanis xclipped:The unclipped box reached about 23,700 units past AutoCAD's own extents, in a drawing only 42,000 units across.
The fix
Intersect the clip boundary with the block's box before the insert transform is applied. An empty intersection is left alone rather than trusted.
One thing worth flagging separately
InverseInsertTransformcannot be used as it is stored.Both DWG and DXF record it as three rows of four with the translation in the fourth column, and
read4x3Matrix/ the DXF reader store it exactly that way.Matrix4's own multiplication reads the translation from the fourth row —GetRows()returns the columns of theMrcgrid, andMatrix4.CreateTranslationwritesM30/M31/M32.So
matrix * pointsilently drops the translation, which for a clip boundary is the whole of what the matrix carries. In the drawing above it is a pure translation of(-730293.09, +197002.18, 0), and ignoring it left the boundary a million units from the block, producing an empty intersection and no clip at all.This PR transposes at the point of use and says why in a comment. Normalising the two matrices at read and write time would be tidier, but it changes a persisted convention in four places (DWG reader and writer, DXF reader and writer) and a per-format round-trip test would not catch a mismatch introduced between the two formats — so it seemed better raised than bundled in here. Nothing else in the library consumes either matrix, which is presumably why this has gone unnoticed.
Tests
New
GetBoundingBoxIsClippedByTheSpatialFilterclips a 100x100 block to a 20..60 boundary and gives the filter a translation stored the way a file stores it, so the transpose is exercised rather than assumed. It fails against the current implementation.dotnet teston this branch: 2314 passed / 17 failed, against 2313 / 17 formasterat 592d70a on this machine — the same pre-existing failures plus the one test this PR adds.Related
#1223, #1224, #1225. With all of them plus DomCR/CSUtilities#23, the computed extents of all eighteen drawings in the sample now agree with AutoCAD's, once entities on frozen layers are excluded as AutoCAD excludes them.