You are not logged in. Please login or register.
QElectroTech → Posts by vadoola
I see the problem:
if info {
//prints info
} else if verbose_output {
//print to stdout
}if the info flag is passed (which defaults to true), it never checks if the verbose flag is used.
Looks like this change was made as part of commit 67557ff on 2022-10-15
In a deep subdirectory, from the compiled result I find the file "entities.rs" with (among other things) this content
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.
At first glance, there's no difference - both do a remarkable job.
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.
Maybe just look at this post: nomicons/wink
https://qelectrotech.org/forum/viewtopi … 299#p20299.
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.
When I change the entries "70 1" to "70 0" the polygons are shown open in LibreCAD.
I therefore think that it should be possible to be implemented in dxf2elmt...
Thanks this gives me a place to start looking.
In summary, it can be said that the order of the parameters is decisive for the original code.
With Vadoola's code, the call in QET would have to be adapted.
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.
So I just did a quick look and test with the latest version in antonioaja's repo that I initially forked from. In order to get the XML on stdout you need to use both the
-i AND -v command line flags.
The -i flag turns off printing the info such as the number of elements that were converted etc, and the -v flag turns off creating the elmt file.
If you use the -i flag without the -v you get something along the lines of
XXX.elmt was created...
Now converting XXX.dxf...If you use
dxf2elmt.exe -i -v -f mydxf.dxf, you get the XML output to stdout.
This works the same in both my repo and antonioaja's. The choice of flags and combinations seems a bit odd to me, and I might make some changes at some point, but it does output to stdout if you set the correct cli flags.
Well it looks like this post sparked some conversation, good to see.
No activity of Antionio since November 8, 2023 : https://github.com/antonioaja
I hope he's all right .... "
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.
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.
ps: size of the binary is very big after cargo build... ~57,6 Mio (60414840) (debug?)
cargo buildcreates a debug build, and they can be pretty big.
cargo build --releasewill create a smaller release build, and also striping the symbols as suggested by plc-user will reduce the size even more.
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.
Hello,
The dxf to elmt conversion program hasn't been updated in over a year, and has a few issues, as well as doesn't support all features of dxf.
I forked the project a couple of weeks ago and started to try and update it some. I don't know how much time I will have to dedicate to it, but I thought I would give it a go to try and fix some of the issues with it, as well as possibly try and add in some of the missing features.
I've submitted a pull request to the original project, and as of yet have heard nothing back (it has only been 1-2 weeks).
If anyone is interested in my fork you can find it at https://github.com/Vadoola/dxf2elmt.
I know QElectrotech links to the original repo, and I'm not suggesting this be updated to point to mine, as I feel like we need to give the original creator more time to respond before we declare it dead/unmaintained. I do hope to try and spend some time updating it however, and if the original author doesn't respond, at some point it might make sense to link to my updated repo.
QElectroTech → Posts by vadoola
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.021 seconds (47% PHP - 53% DB) with 6 queries