Search options

Good catch, I'll get that corrected.

This is part of why I wanted to see the original dxf that created these single point polygons (thank you for attaching it). I agree that a single point polygon makes no sense, and these could possible be lines that extend out in the direction away/into the viewport, and they are represented as single point polygons in the exported dxf. I just want to make sure that these aren't being created by some bug in dxf2elemt that is dropping points in the dxf that should exist in the resulting element file. If after some testing we can safely say there is no bug and these are represented in the dxf as single point polygons, it would be easy to filter those out simply by looking at the length of the vector holding the points. Similarly if we end up with a polygon with only two points, it's easy to recognize that and convert it to a line.

I agree, converting multiple splines that form a circle into a circle element within QET would be preferred, as would getting rid of extra polygons that overlap and aren't seen, and polygons with multiple points that form a straight line. All of these are great ideas and something that I can try and work on, however they can get far more complicated than just checking the number of points. With a straight line multi-point polygon I need to do some math on it to determine if it's a line.

With the multiple spline circles, or overlapping polygons I need to look at multiple elements in combination to determine the shape, this gets far more complicated, as now not only am I trying to determine a shape from multiple elements, but I might need to do this processing on multiple combinations of splines withing the dxf. each new object would significantly increase the number of combinations that need to be looked at.

I could try and start with an easier route. After I get clean up and get the block importing finalized I could try and do some shape testing for circles made of splines etc, just within each block. This would reduce the number of combinations that need to be processed.

I think these points that you have brought up are very worth goals, and I'll add them to the issue tracker for the project, but they are quite complicated features, and I'll probably concentrate on some other simpler clean up and fixes before I try and tackle them.

Hmm, when I initially made my announcement I had only tested the CLI, since I hadn't realized antonioaja had made changes to the argument parsing, I just assumed it had still worked from QET. This time around I acatually tested it in QET and it seemed to work fine on my machine, although maybe I made a mistake. I'm currently testing it on Windows, and I now see that I have a dxf2elmt exe in both C:\Program files\QElectrotech\bin as well as C:\Users\Vadoola\AppData\Roaming\qet\binary. Perhaps I dropped the exe in he wrong place and it was using the old 0.30 release version from antonioaja repository. I'll take another look into this, and do a more thourough testing job this time around.

I agree that 100 does seem like a lot and could make the resulting element unnecessarily large. This should be an easy change, I'll do some testing to see how 10-12 points do, and make sure it still works well.

Completely agree, I can change the default behavior to round to 2 decimals of precision.

While doing some testing this past week on QET element files I found on github, there were a few I found converted with (I believe) the old C++ dxftoelemt that had polygon's with only 2 points. I created an issue (https://github.com/Vadoola/dxf2elmt/issues/120) to try and filter those out and convert them to lines. I could also easily filter out polygons with only 1 point and just not write them out, but I'll take a closer look at the file you attached and try to find out WHY there are single point polygons in the first place. Perhaps removing them isn't the proper way forward and they have a purpose and need to be handled differently (like a point that needs a thickness or something, that is converted to a circle element?)

Antonioaja has also responded to my pull request (https://github.com/antonioaja/dxf2elmt/pull/3). I asked for clarification if he is fine with my fork being the QElectrotech recommended fork, but it sounds like he said the project did what he needed and had no real plans to continue development.

Since I don't really have access to the Antonioaja's issue tracker I started issues on my own.

I created two issues that might be relevant: https://github.com/Vadoola/dxf2elmt/issues/8 and https://github.com/Vadoola/dxf2elmt/issues/4

I started digging into this a little last night just looking at that circle dxf in the initial issue. It looks like it's using an Insert Element which is why it's not working. I'm not an expert on dxf so I don't know if it's this specific dxf or all blocks in dxf that use an Insert Entity.

This is one the things I want to focus on first, as I feel this is a big limitation.

Perfect you pointed me to exactly what I need, since the info is already there it's a simple 2 line fix putting the correct info int he XML instead of having it hard coded to true or false. So far I've only tested it on the arrow.dxf you provided and the 4_inlet.dxf scorpio810 provided in this thread https://qelectrotech.org/forum/viewtopic.php?id=2265 that caused Antonioaja to change it from closed=true to closed=false. But it works well and correctly handles both of them, as can be seen int he 2 attached elmt files.

As my changes so far have been a some simple organizational changes, and updating some dependencies, I wouldn't expect there to be much if any difference. Hopefully going forward as I try to add some more features I won't break anything.

Just saw that after already fixing it on my end. I pretty much did the same thing, except instead of using

if self.flags & 1 == 0 {

I used

if !self.get_is_closed() {

Same result in the end.

I looks like the last release and binary are dated 2022-07-21, but there was a commit on 2022-07-22 where Antonioaja switched from manually parsing command line arguments to using the clap argument parsing crate. I imagine that's where this discrepancy is coming from. I'll see what I can do to correct this. Probably no reason to update how QElectrotech is calling dxf2elmt if I can resolve the difference.

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.

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.

cargo build

creates a debug build, and they can be pretty big.

cargo build --release

will create a smaller release build, and also striping the symbols as suggested by plc-user will reduce the size even more.

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.