Split out of #55, which decoded MLINESTYLE, MLEADERSTYLE,
ACDBDETAILVIEWSTYLE and ACDBSECTIONVIEWSTYLE and declined this one.
ODA v5.4.1 §20.4 has no prescription for TABLESTYLE, so it needs the
joint-boundary derivation. What is already measured (see
ARCHITECTURE.md §7d.4, reproduce with
cargo run --release --example probe_token_scan -- samples/arc_2013.dwg 101):
- Budgets between the end of the common object data and the
data-stream boundary: R2004 1849, R2010 6836, R2013 6844, R2018 5820.
R2004 is an order of magnitude smaller than R2010+, so the two are not
the same record shape — the R2004 files also carry a separate
CELLSTYLEMAP object.
- Structure on R2010+: a 52-bit header followed by four cell-style
blocks of 1738 / 1696 / 1696 / 1662 bits. The string stream names
them: ["Standard", "", "Table", "", "_TITLE", "", "_HEADER", "", "_DATA"].
- Each block ends in six 168-bit border sub-records of the shape
CMC (44) + 36 bits + BD (66) + 22 bits — six borders being top,
bottom, left, right and the two inner ones. Before them the block runs
CMC + 64 bits + CMC + BD + 10 bits + 4 × BD + 2 × BD + 32
bits.
- Decoded anchors on
arc_2013.dwg handle 101: the leading CMC of
each block is the 0xC8…… "no colour" method, the second is ByBlock
(0xC1000000), and the doubles are 4.5 / 6 (text heights),
1.5 (margins) and 1.125 (border double-line spacing).
Why it was declined rather than guessed: each corpus file carries
exactly one TABLESTYLE record, so the joint-boundary constraint has
one instance per band instead of the 24 VISUALSTYLE or 11 view-style
records that made those derivations unique. A 52-bit header alone admits
thousands of parses over B/BS/BL/BD/RC/CMC, and the block boundaries
vary by ±42 / −34 bits, so the block layout has variable-width fields
whose positions are not pinned.
The way in is probably a drawing with more than one table style, or a
cross-version joint search that requires the same token sequence to
close the R2010, R2013 and R2018 records at once (they differ by 8 and
1024 bits respectively). Ten records on the corpus; decoding it would
move the aggregate from 90.3% to roughly 90.7%.
Split out of #55, which decoded MLINESTYLE, MLEADERSTYLE,
ACDBDETAILVIEWSTYLE and ACDBSECTIONVIEWSTYLE and declined this one.
ODA v5.4.1 §20.4 has no prescription for TABLESTYLE, so it needs the
joint-boundary derivation. What is already measured (see
ARCHITECTURE.md §7d.4, reproduce with
cargo run --release --example probe_token_scan -- samples/arc_2013.dwg 101):data-stream boundary: R2004 1849, R2010 6836, R2013 6844, R2018 5820.
R2004 is an order of magnitude smaller than R2010+, so the two are not
the same record shape — the R2004 files also carry a separate
CELLSTYLEMAP object.
blocks of 1738 / 1696 / 1696 / 1662 bits. The string stream names
them:
["Standard", "", "Table", "", "_TITLE", "", "_HEADER", "", "_DATA"].CMC(44) + 36 bits +BD(66) + 22 bits — six borders being top,bottom, left, right and the two inner ones. Before them the block runs
CMC+ 64 bits +CMC+BD+ 10 bits + 4 ×BD+ 2 ×BD+ 32bits.
arc_2013.dwghandle 101: the leadingCMCofeach block is the
0xC8……"no colour" method, the second is ByBlock(
0xC1000000), and the doubles are4.5/6(text heights),1.5(margins) and1.125(border double-line spacing).Why it was declined rather than guessed: each corpus file carries
exactly one TABLESTYLE record, so the joint-boundary constraint has
one instance per band instead of the 24 VISUALSTYLE or 11 view-style
records that made those derivations unique. A 52-bit header alone admits
thousands of parses over
B/BS/BL/BD/RC/CMC, and the block boundariesvary by ±42 / −34 bits, so the block layout has variable-width fields
whose positions are not pinned.
The way in is probably a drawing with more than one table style, or a
cross-version joint search that requires the same token sequence to
close the R2010, R2013 and R2018 records at once (they differ by 8 and
1024 bits respectively). Ten records on the corpus; decoding it would
move the aggregate from 90.3% to roughly 90.7%.