Entities with type SOLID are not handled properly

[opelline-sito]

I tried parsing files with entities of the types LINE, POLYLINE and POINT, and they all came out as they should.

I also had a test with a polygon which should have the type SOLID (it might also be HATCH by looking at the source, I just know this is the type of data I need to read). However, this time the "entities" array is empty.

I've attached the .dxf-file here (but renamed it with a txt-extension for github upload):
areas_test.txt

[Serthys]

I thinks it's a HATCH entity with pattern name "SOLID" (HATCH documentation).
Looking at the source I see that hatches are not supported yet but on your dxf file looks like a code 93 with the number of vertices and then n 10 and 20 with the x and y values. It shouldn't be hard to add a basic support.

[opelline-sito]

If that could be done it would be deeply appreciated!

[Serthys]

@opelline-sito I've managed to read the hatches on your sample but running the tests I ran into some problems with the file /test/data/blocks.dxf. It contains more complex hatches and it breaks.

I could make it work but it's hard to fix when the documentation is missing some codes, for example in the hatch documentation I linked before the 93 code is missing, I guessed it was just the vertex count but apparently hatches can contain multiple polylines distributed in multiple arrays with different meanings.

If you can tell me exactly what information you need I can try to do the simple thing instead of all of it.

[bzuillsmith]

Interesting. Yeah, I imagine HATCH entities get pretty complex. @Serthys we could add just partial support for now. If you have this example working, perhaps we can add some code to skip other examples like the blocks.dxf file.

[Serthys]

I think I found the problem from my last comment, I thought I had an infinite loop problem somewhere but the problem is the block.txt massive size (108141 lines).

When the comparator fails it tries to do a diff using node_modules\approvals\lib\Reporting\Reporters\nodediffReporter.js:34 it takes way too long. I left it 30 minutes and it didn't end.

Probably the test on block.txt should be broken in smaller tests to solve this problem but I don't know what it actually tests. I commented it for now so we can execute the other tests (although the postRunCleanup complains about the unused blocks.approved.txt ¯_(ツ)_/¯ )

I've submitted the pull request on #45.

[bzuillsmith]

Ah, I see. Makes sense. It was just a huge file I threw in as a general integration test. I don't even remember everything in it. You are right though, we should just use smaller tests for specific features

[bzuillsmith]

@Serthys tests are fixed now.