Closed brettfo closed 7 years ago
For the sanity checks on e.g. leaders and polylines, Rhino and RhinoCommon have the solution to add a IsValid method to each entity / kind of geometry. This allows for files to be read and written, but also allows the developers using this library to check themselves what to do with these potentially invalid cases.
The IsValid logic can be added / extended for each entity, e.g. having values to check if certain Radii in arcs are =< 360, or other sanity checks on geometry.
My thinking for the last two items is something like this:
Line types: When reading a file, don't worry if line types aren't specified; I still want to be able to read invalid files. When writing a file, if an entity specifies a line type that isn't in the table, add a default one so that the file on disk is valid. This would require an extra scan through the file on write, but I think I can shoehorn this into pointer resolution.
LEADERs and POLYLINEs: I can get creative with ListWithPredicates and some internal
visibility and a custom reader to allow reading an entity with < 2 vertices, but the public
entry points would throw if the consumer tried to remove a vertex or clear the list. The constructors would also have to have the >= 2 restriction set. There is still the possibility that a LEADER with < 2 vertices could be read from disk and immediately written back out, but I don't think that's a problem that needs to be solved here.
As a quick follow-up, I've fixed the line-type issue. The only remaining item for this issue is the LEADER and POLYLINE vertex counts.
All cases mentioned by this issue should have now been addressed.
This is a larger issue encompassing many smaller items, specifically, but not necessarily limited to:
List<T>
should be replaced with something likeListWithPredicate<T>
that will throw onnull
or otherwise invalid values. This will make a lot of internal null checks go away. COMPLETE WITH c61c4636d0ab5eb7cabab276622d3dce36251c11LEADER
ANDLWPOLYLINE
WITH 905f3efcea1ec6bd4f84fc15b4fc873e529acee9 AND COMPLETE FORPOLYLINE
WITH d1d39460be6ba5d4071ebd19e9875bbb9d53f512During all of this, I'd like to follow the idea that this library will be able to open nearly any DXF file, valid or otherwise to avoid the situation that AutoCAD is in, namely that it's the most complete/correct implementation but it's rather fussy about what it will accept and easy to make crash.