Problem parsing $SHAPES section when opening a GenCAD file

[cyrozap]

I get the following error when I try to open a certain .cad file:

Failed to parse GenCAD file: the $SHAPES section was not parsed properly

The file in question can be found here:
ASUS TUF GAMING B650-PLUS WIFI 1.04 BoardView File.zip

OpenBoardView version is latest from git (8528b80).

[swiftgeek]

That file is crashing CAMCAD (4.14.312.6), so something went horribly wrong there

Removing contents of $SHAPES, naming unnamed signal WTF and adding missing sections makes it parse in my build of OBV (it's quite a bit behind), so I suspect some crazy thing to be contained in that section alone.

In $SHAPES section we can see that every pin is referring to bogus padstack XXX
INSERT SMD appears before instead of after shape.

So when instead of removing $SHAPES contents, I moved starting INSERT SMD to end of that section and inserted XXX padstack definition (copying first one with no changes but name) I got working (in OBV) GenCAD file.

Original file is so corrupt/mangled it cannot be used even to create stencils for chips.
I don't believe that CAMCAD could provide such botched $SHAPES section, so I would guess it also went through some another tool to create such result.

[piernov]

Similar issue with this one where the $SHAPES section does not start with SHAPE but instead INSERT. Not sure what to do here, seems like a bogus file but if there's a tool that actually produces these maybe we should try to take it into account (but that's a pain).
Asus_X1403ZA_BV.zip

[swiftgeek]

I think a conversion/repair script would be more feasible here, since those files are so deeply broken (and thus most of the contents those files can be discarded since it cannot be correlated back). A script would also give opportunity to the end user to use dummy padstack that is most suitable for the board (basically smallest pad size on board - which would be different on mobile devices if asus still makes those)

Since GenCAD is a standard widely used in industry, it wouldn't be so great to taint the interpreter in OBV, which would definitely impact its maintainability in the future.