Well it looks like this post sparked some conversation, good to see.
I hope so too, I know how things can get and they may just have other priorities, so despite the lack of updates, I didn't just want to assume the project was unmainted without trying to reach out.
scorpio810 wrote:Program work well in a terminal with CLI, not when I put the binary dxf2elmt in ~.qet/binary/ and I use QET element editor
menu Import DXF, not stdout?
So far I'm made some minimal changes, and in my tests it seems to be working, but I will admit I have not fully tested it yet, and only ran it from the command line. I thought the stdout support was added by Antionio with the -v flag. I can't think of any reason my changes would have broken that, but I'll take a look, as it's certainly possible I made a mistake.
scorpio810 wrote:ps: size of the binary is very big after cargo build... ~57,6 Mio (60414840) (debug?)
creates a debug build, and they can be pretty big.
will create a smaller release build, and also striping the symbols as suggested by plc-user will reduce the size even more.
plc-user wrote:What bothers me more about dxf2elmt:
The default behavior for polygons of dxf2elmt seems to be "closed=false", but for QET the default behavior is "closed=true". (see attachments)
This change to use closed=false by default was made by Antonioaja as the solution to a bug found by scorpio810. This original post about this is at https://qelectrotech.org/forum/viewtopic.php?id=2265. I'll have to do a bit of digging to determine what the proper solution is here. If it should be closed or not, and if it should be closed, what else was going wrong with the dxf in the other thread.