Open stuartpb opened 5 years ago
Okay, my initial read of the issue misstated the problem.
I think the bug lies here: when the file is being read in as binary, the description should be truncated at the first null.
Hey, sorry it took so long to get my eyes on this. This is basically the dark corner in the STL "spec" and its resolution is ambiguous.
From wikipedia:
A binary STL file has an 80-character header (which is generally ignored, but should never begin with "solid" because that may lead some software to assume that this is an ASCII STL file).
Which is exactly what we are seeing here. Due to the streaming nature of this library, I'm not sure there is a good way to approach this. Here are the constraints that we have to deal with:
\0
bytes)solid <description of arbitrary length>
.So the question is, when do we know that the stl is binary vs ascii when the first bytes are solid
?
I think the best course of action here would be to read ahead and make the ascii/binary determination later on when a "facet"/"endfacet" token is reached.
Yeah, I mean, the way I was thinking you'd do it is you'd just read the first 81 bytes before emitting anything, and if the 81st character starts a binary STL, that's your clue that the first 80 characters were an ASCII header - it sounds like that's more or less what #4 is set to do.
Test case: Download this file and parse it with
stl.toObject
.Expected behavior: The object description should be "BRH5-GAUNTLET-LITE", and the rest of the object should contain all the facets defined in the file.
Observed behavior: The object description contains the entire first chunk read.