ASCII versus Binary detection and fallback

[patyork]

An outstanding issue is some corruption/errors in an ASCII STL file will cause numpy-stl to fallback to a binary load, which can lead to the MAX_COUNT overrun exception. The ASCII STL errors that cause this include:

• An extra vertex in a facet
• A missing vertex in a facet

Strictly speaking, the smallest complete ASCII STL file is, I believe, 186 bytes. This file would include the following keywords: solid facet normal outer loop vertex endloop endfacet endsolid along with the normal and vertex values.

I think that the following decision tree should be included, for a strict ASCII/Binary determination:

• File includes all keywords from above in standard UTF-8 ASCII outside of the header/solid name
  • ASCII
• File includes some but not all of the above keywords
  • Corruption warning, or perhaps some extra checks.
• File size < 196 bytes
  • Extra validation, or default to Binary
• Else
  • Binary

There would be no fallback to Binary after an ASCII parsing error. While it is technically true that a Binary file could contain all of the above keywords, the odds are low that it would be a valid STL file (I haven't checked this) and that this would occur from an actual STL file not designed to break numpy-stl.

We can then remove the MAX_COUNT arbitrary cutoff. The loading process, I think, would be greatly simplified, and some better exceptions can be thrown (more descriptive; can be recoverable/unrecoverable; can add a loading mode of "strict"/"flexible"; etc.).

As an example, PyCam did it this way when they implemented their own STL loader.

[wolph]

It's been a while, but I believe this might be fixed now.

It should be noted that as long as your file handle is seekable (which most file handlers except for stdin are), it can still recover. So I think it should be versatile enough to fall back now since it defaults to ascii.