Summary
When loading a DWF file published from AutoCAD 2021, the binary WHIP/W2D parser (w2dBinary.js) hits an unrecognized single-byte opcode (0x07) partway through the ePlot vector stream. Per the current implementation, decoding intentionally stops at that point (rather than guessing an operand length), so everything after that byte offset in the sheet is never rendered.
Diagnostics from the app
W2D_BINARY_PARTIAL: 1 unsupported opcode(s); first at byte 18429:
Unsupported/unknown W2D single-byte opcode 0x07.
(com.autodesk.dwf.ePlot_20231585-46A4-4A84-B6C4-EFA2A800EBE0/20231587-46A4-4A84-B6C4-EFA2A800EBE0.w2d)
document.pages / entity count before stopping: 905 entities parsed successfully before the break.
Renderer: WebGL, 698 draw ops reported for the sheet in question.
File details
Source app: AutoCAD 2021 (English), per the stream header: (W2D V06.00)(Creator 'AutoCAD 2021 - English 2021 (24.0s ...)
DWF package structure: standard DWF 6.x ZIP package (manifest.xml + com.autodesk.dwf.ePlotGlobal + one com.autodesk.dwf.ePlot_ section)
Affected stream: com.autodesk.dwf.ePlot_20231585-46A4-4A84-B6C4-EFA2A800EBE0/20231587-46A4-4A84-B6C4-EFA2A800EBE0.w2d
Stream size: 1,329,530 bytes (uncompressed)
Failing offset: byte 18429 (opcode byte itself is 0x07)
Byte context around the failure (from the raw stream)
Hex dump, offset 18389–18489 (failing byte in bold position, offset 18429):
f8 00 00 0c bf 15 24 00 00 00 00 00 0c f1 17 e8
f5 00 00 00 00 0c 8f 03 73 f7 94 ff f1 ff 0c 71
fb 67 ff 90 00 b5 fb 46 [07] 03 ef f6 34 11 d8 d8
a6 b2 0b 00 ab ff d8 d8 a6 b2 6d fd 00 00 d8 d8
a6 b2 07 03 07 00 c5 ff d8 d8 a6 b2 94 02 00 00
d8 d8 a6 b2 78 fd ab ff d8 d8 a6 b2 07 03 ed ff
90 00 d8 d8
Decoded sequence immediately before the failure (all successfully parsed by the existing implementation), for reference:
0x0c <2x 16-bit relative point> // draw line
0x0c <2x 16-bit relative point> // draw line
0x46 ('F') // fill on
0x07 // <-- unsupported opcode starts here
Note the repeating 4-byte pattern d8 d8 a6 b2 followed by 4 variable bytes that recurs several times right after the failure point — this may be a clue to the structure that 0x07 introduces (e.g. a repeated-record / point-list construct), but I don't have the original WHIP toolkit specification to confirm the operand layout, so I'm not proposing a specific implementation — just flagging the pattern in case it helps whoever picks this up.
Expected behavior
Ideally, opcode 0x07 gets properly implemented (correct operand length and semantics) so the rest of the sheet decodes instead of stopping at byte 18429.
Environment
Package: @flyfish-dev/cad-viewer (via bundled dwf-viewer dependency)
File origin: AutoCAD 2021, DWF 6.x ePlot package
Reproduced with: local Vite dev project using CadViewer with renderer: 'auto'
Attachments
I can attach the source .dwf file (or just the extracted .w2d stream) if that's useful for reproduction
LAM001-29079-ED.7-1°P-M2C-1A.zip
Summary
When loading a DWF file published from AutoCAD 2021, the binary WHIP/W2D parser (w2dBinary.js) hits an unrecognized single-byte opcode (0x07) partway through the ePlot vector stream. Per the current implementation, decoding intentionally stops at that point (rather than guessing an operand length), so everything after that byte offset in the sheet is never rendered.
Diagnostics from the app
W2D_BINARY_PARTIAL: 1 unsupported opcode(s); first at byte 18429:
Unsupported/unknown W2D single-byte opcode 0x07.
(com.autodesk.dwf.ePlot_20231585-46A4-4A84-B6C4-EFA2A800EBE0/20231587-46A4-4A84-B6C4-EFA2A800EBE0.w2d)
document.pages / entity count before stopping: 905 entities parsed successfully before the break.
Renderer: WebGL, 698 draw ops reported for the sheet in question.
File details
Source app: AutoCAD 2021 (English), per the stream header: (W2D V06.00)(Creator 'AutoCAD 2021 - English 2021 (24.0s ...)
DWF package structure: standard DWF 6.x ZIP package (manifest.xml + com.autodesk.dwf.ePlotGlobal + one com.autodesk.dwf.ePlot_ section)
Affected stream: com.autodesk.dwf.ePlot_20231585-46A4-4A84-B6C4-EFA2A800EBE0/20231587-46A4-4A84-B6C4-EFA2A800EBE0.w2d
Stream size: 1,329,530 bytes (uncompressed)
Failing offset: byte 18429 (opcode byte itself is 0x07)
Byte context around the failure (from the raw stream)
Hex dump, offset 18389–18489 (failing byte in bold position, offset 18429):
f8 00 00 0c bf 15 24 00 00 00 00 00 0c f1 17 e8
f5 00 00 00 00 0c 8f 03 73 f7 94 ff f1 ff 0c 71
fb 67 ff 90 00 b5 fb 46 [07] 03 ef f6 34 11 d8 d8
a6 b2 0b 00 ab ff d8 d8 a6 b2 6d fd 00 00 d8 d8
a6 b2 07 03 07 00 c5 ff d8 d8 a6 b2 94 02 00 00
d8 d8 a6 b2 78 fd ab ff d8 d8 a6 b2 07 03 ed ff
90 00 d8 d8
Decoded sequence immediately before the failure (all successfully parsed by the existing implementation), for reference:
0x0c <2x 16-bit relative point> // draw line
0x0c <2x 16-bit relative point> // draw line
0x46 ('F') // fill on
0x07 // <-- unsupported opcode starts here
Note the repeating 4-byte pattern d8 d8 a6 b2 followed by 4 variable bytes that recurs several times right after the failure point — this may be a clue to the structure that 0x07 introduces (e.g. a repeated-record / point-list construct), but I don't have the original WHIP toolkit specification to confirm the operand layout, so I'm not proposing a specific implementation — just flagging the pattern in case it helps whoever picks this up.
Expected behavior
Ideally, opcode 0x07 gets properly implemented (correct operand length and semantics) so the rest of the sheet decodes instead of stopping at byte 18429.
Environment
Package: @flyfish-dev/cad-viewer (via bundled dwf-viewer dependency)
File origin: AutoCAD 2021, DWF 6.x ePlot package
Reproduced with: local Vite dev project using CadViewer with renderer: 'auto'
Attachments
I can attach the source .dwf file (or just the extracted .w2d stream) if that's useful for reproduction
LAM001-29079-ED.7-1°P-M2C-1A.zip