Repository navigation
ACIS record: seven unknown bits before the revision GUID; is the missing SAB envelope keyed on the AcDs flag or unconditional R2013+? #68
Description
From #67: the three sample_AC1032.dwg ACIS records agree on the first two of the seven bits between the R2013+ marker and the RFC-4122 v4 revision GUID (1, 0) and diverge after; B,BB,BB,BB and 3B,BB,BB both fit. Separately, whether the inline SAB envelope's absence (data record moved to AcDb:AcDsPrototype_1b per section 24.2.2.3) keys on the flag or is unconditional R2013+ is untestable on this corpus — every ACIS record here sets the flag. A flag-clear or non-R2018 3DSOLID decides both; the decoder fails the boundary check rather than guessing. Also: pre-R2010 ACIS records stay Unhandled because checked_inline's boundary only exists for R2010+ — wiring the R2004 obj_size_bits boundary covers them once a corpus file exists.
Activity
DrunkOnJava commentedon Oct 27, 2026
Status on one point (main 2bab7b2): "pre-R2010 ACIS records stay Unhandled" is stale. #283 reads a version-2 binary (SAB) envelope byte by byte to its fixed terminator, because the spec gives no length. The two 3DSOLIDs and one REGION of each of ACadSharp's R2004, R2007 and R2010 saves, all 9 records that errored, now close. A version-2 text (SAT) file is refused with
Unsupported. The corpus run (CI run 40503137263) skips no 3DSOLID or REGION.Both questions in the body are still open: the seven unknown bits before the revision GUID, and whether the missing inline SAB envelope keys on the AcDs flag or is unconditional from R2013. Nothing on
mainsettles either; as the body says, a flag-clear or non-R2018 3DSOLID decides both.