You are not logged in. Please login or register.
QElectroTech → Posts by vadoola
Interesting for check dxf convertion with new dxf2elmt new builds.
https://github.com/LibreDWG/libredwg/tr … /test-data
Nice find, I've been wanting to find a bunch of files I could test against.
I've noticed that many more DXF files are now being converted,
whereas previously they would generate an error and can't be converted....
So it sounds like it's well worth upgrading to the master branch, and its pretty easy to make it compile.
Do you want to issue a pull request, or should I just make the few changes on my branch?
Edit: I tried to go to last git main branch but dxf2elmt code can't compile after patched cargo.toml and use cargo update to update cargo.lock...
error[E0599]: no method named `get_is_closed` found for reference `&dxf::entities::Polyline` in the current scope
--> src/qelmt/polygon.rs:60:26
|
60 | closed: poly.get_is_closed(),
| ^^^^^^^^^^^^^
|
help: there is a method `set_is_closed` with a similar name, but with different arguments
--> /home/laurent/new_dxf2elmt_vadoola_fork/target/release/build/dxf-a92690d5c3960b91/out/generated/entities.rs:1726:5
|
1726 | pub fn set_is_closed(&mut self, val: bool) {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It looks like the function was renamed at some point from get_is_closed to just is_closed, the source between the 2 is identica.
0.5.0
pub fn get_is_closed(&self) -> bool {
self.flags & 1 != 0
}Master
pub fn is_closed(&self) -> bool {
self.flags & 1 != 0
}I haven't tested it properly, but just replacing all the .get_is_closed() function calls with .is_closed() makes it compile for me
@vadoola: FYI https://qelectrotech.org/forum/viewtopi … 496#p20496
https://github.com/ixmilia/dxf-rs/issues/46You use last dxf-rs old tag or master git?
As of right now, dxf2elmt is using the latest official tagged version of dxf-rs from crates.io, which is 0.5.0, tagged all the way back in September 2021.
I have been considering on updating to use the master branch from git, even though it looks like development on dxf-rs has slowed to a crawl there are still updates to the master branch that have happened int he last 3 years.
I think I've seen at least 2 or 3 of these where the dxf reading fails due to some unsupported code point. The past couple of weeks since I tagged 0.4.0 has been mostly investigating issues, and brainstorming. I may try and update dxf-rs to the master branch and see if that breaks anything, and if it fixes any of these reported issues as well.
Hello Laurent and plc-user,
Hello Vadoola!
Salut Laurent !About the Texts / Fonts:
I don't know, where to find "official" information about fonts in QET, so I noted what I found out about fonts in sources of QET_ElementScaler:
https://github.com/plc-user/QET_Element … nts.h#L301
If no font size is defined in the font-tag it defaults to "9" in QET what often is too big!So the question is:
Do texts in dxf include a size? I guess so.
So you should add that info to the font-tag in elmt-file, Vadoola.
I'll add it to the list. It looks like the dxf has a text height property, I'm assuming it would be in the same units are the rest of the dxf, ie it's a height in mm, or inches, etc. I would have to convert that into a font size. It looks like I already need to figure out how to do some font processing. One of the forums posts mentioned text not being in the correct spot. I figure out why and documented it in the Issue https://github.com/Vadoola/dxf2elmt/issues/7. Essentially if the horizontal and vertical alignment on the text are not the default (top left), then you need to calculate the location based on a different set of coordinates, and the font rendering. As part of trying to add that in, I can also try to figure out converting the text size in the dxf into a proper font size.
Hallo plc-user
Hello Vadoola,
If you read in the file sequentially and output everything immediately to stdout, the definition-line values can not be correct. As far as I know, the necessary information is not in the dxf...
The original version of the code was doing exactly that, essentially just converting it piecemeal and dumping it to stdout.
Part of the big change that was released in my version 0.4.0 was doing exactly what you are doing, reading the dxf in, converting to to element structures in memory and then writing it out. I made this change exactly for the reasons you are talking about, if I needed to do some processing on it, such as other things we had discussed, determining that a polyline is really a circle and concerting it to an ellipse, etc.
So it sounds like I'm heading in the right direction, I just need to keep ticking away at improvements. I already looked a bit into scaling it and such, I'll take a closer look at how you do it in QET_ElementScaler. Thanks
Ziemlich verwirrt ... Gute Nacht!
Ich bin auch ziemlich verwirrt, aber das liegt vielleicht daran, dass mein Deutsch zwar viel besser ist als mein Französisch, aber nicht gut genug, um dies zu verstehen oder zu schreiben, ohne Google Translate zu verwenden.
da das Kommandozeilenprogramm (zumindest in der letzten Version, die ich kenne) die Werte für die sog. „Definition-Line“ des Elements nicht korrekt berechnet und daher im Diagram-Editor die Elemente nicht korrekt dargestellt werden.
plc-user, können Sie weitere Informationen dazu bereitstellen, was Sie hier meinen, damit ich versuchen kann, der Sache nachzugehen? Oder ist das etwas, das Sie schon einmal erwähnt haben und das ich bereits in den GitHub-Problemen dokumentiert habe?
Hoffentlich ist diese übersetzte Nachricht verständlich.
Hello Laurent, plc-user,
@plc-user that multi-info messagebox looks like a useful way to do it. I agree the box should only popup when it's needed to provide info to a user, if everything goes well they should just get the element in the editor.
In verbose mode to print the element to stdout there shouldn't be a lot of information I think if everything goes well it's mostly just created <file_name>.elmt or something like that I would need to go double check. Clearly though something slipped through in my commit. The "Remove Polygon with one less points" was something I had in there when I was testing the most recent couple of commits, which doesn't convert single point polylines, and converts dual point polylines from Polygons to Line Elements. I thought I had removed them all from the code before commiting, but clearly missed something.
Hello Laurent,
One hour is a long time for a user to be waiting for a result, and there should be no need for that. I'm not sure how reasonable it is to assume a user will just look at the log file after a few minutes though either.
One thing on the list is to add some better logging / error handling into dxf2elemt. Right now on most errors it just panics and unwinds the stack printing an error to stderr.
If the program were to return an error code, ie 0 on success any anything else is an error, I assume you could capture that in QET? That way if dxf2elemt fails as it did with the above code pair issue, QET could capture that failure and pop up an alert or something saying "Conversion failed, see log for further information"
Do dxf files include scaling or dimensioning for the existing values?
When I look at the file Laurent attached in this post (https://qelectrotech.org/forum/viewtopi … 379#p20379), I see a value of 0.7158 for the terminal strip width, for example. That won't be millimetres and inches don't seem to be the unit for the values either. A suitable value might be something like 35 mm, as the terminal spacing (from screw to screw) would then be about 5 mm or 2/10 of an inch.
Since this drawing has to be scaled anyway in order to use it sensibly in QET, it would be very practical if the dimensioning of the values came directly from the dxf file. Then no additional effort would be required to obtain a suitable size of the element.
So doing a quick look into it and found: "
AutoCAD 2000 (AC1015) the INSUNITS variable was introduced. This variable defines the drawing units" so it would depend on what version of DXF as to whether or not I could get this information.
If the files doesn't have scaling we might need to come up with a way to pass parameters to the underlying exe. After selecting the dxf QET has a popup with options that could be added, scaling spline steps etc maybe? I could possible add some GUI and a window to dxf2elmt itself but it will increase the size. If the main GUI interaction is from withing QET it would probably make more sense for QET to handle it, as it already brings along Qt, and dxf2elmt doesn't need to bring it along as a dependency.
Hello Vadoola,
Hallo plc-user./dxf2elmt 05DI-AD16DIX-10.dxf
Error: Failed to load 05DI-AD16DIX-10...
Make sure the file is a valid .dxf file.Caused by:
the code pair '[@110865]340/962' was not expected at this time: expected 0/ENDSEC at line/offset 110865
A quick look shows this is an old issue, it gives the same error with the last released version from antonioaja. It appears the issue is the dxf crate (Rust term for a library) itself failing to parse the file, and it looks like it's an XRECORD entity that's failing.
The DXF crate unfortunately hasn't had a release in 3 years, although the last commit on github was 6 months ago. I did a quick look around when I forked this code and was updating crates to see if there was a better and or more maintained dxf crate for Rust and didn't find one. I'll have to dig into this more to solve the issue, but it may require pulling the dxf crate direct from the github master branch, or even forking the crate to try and update it myself. Having to maintain my own fork would be unfortunate as I only have so much time, so we will see when I get a chance to dig into it a bit more.
2. I couldn't able to import dxf file. It is showing warning and saying that large file will take more time but it didn't import after a hour also.
An hour is a very long time. A couple of questions, were you using DxfToElmt or dxf2elmt?
How big was this dxf file and what was in it? If the DXF was a full drawing, I imagine importing that as an element wouldn't be very efficient, you would probably want to break it up into components and import it.
Any change you would be able to share the dxf file (privately if you can't share it publicly) I can try and do some testing against dxf2elmt.
Hello Scorpio810 and plc-user,
Support for blocks has now been added. The most recent commit 53b3b94 has block support.
There was a pretty big overhaul of the way I handled the conversion, and it's possible some regressions have snuck in that I am unaware of. There are 2 regressions that I do know of:
The parameter to pass spline steps is currently being ignored
The parameter to choose between Text and Dynamic Text is also ignored, but it now defaults to Dynamic Text
I intend to clean both of these up, but I thought now would be a good time to get some more people testing it and looking for issues. Then after I fix the 2 issues above, and any other related ones, I'll tag it as a new revision.
For what it's worth, I have forked the dxf2elmt program, and have started making changes. I have a version of it offline that supports blocks without exploding them first in something like QCad. I had hoped to clean it up and release it last week, but sometimes life gets in the way of our best intended plans. Hopefully I'll finish cleaning it up soon, and after that people won't need to worry about if there DXF file has blocks or not.
Hello Vadoola,
the angles for the graphic element "arc" are available as integers without decimal places in QET.
Good catch, I'll get that corrected.
Hello Laurent
Thanks Vadoola for fixing stdout we can use now your dxf2elmt binary on QET element
You're welcome. I disabled the info printing by default which cleared this up. It occurred to me last night that really a better solution would be to make the info and verbose flags mutually exclusive. The info is on by default if you are running it from the CLI, but passing the -v flag disables the info, it's one or the other. I'll create an issue to document that, but I won't worry about it right away.
but FYI build make some warnings:
Sorry, you checked out my master branch which is in a partially complete state. If you grab commit 03efbd8, that has the stdout fix, but shouldn't generate any warnings.
The master branch commit 8309837 has some partially completed restructuring. I'm adding in some code to read the DXF and store the element information before writing it out to XML. This should make it easier for some entities to reference other parts of the drawing (such as blocks), and I believe creates some better encapsulation. Rust by default warns on dead code, functions and structs that are never used, code that can't be reached etc. None of this new code to store the element information from the DXF is called anywhere, hence the warnings. In the main.rs there is line 42:
mod qelmt;This tells rust the qelmt module (similar to a C++ namespace) exists. If you comment it out, rust won't compile it and all the warning should go away. I had meant to do this before committing, but obviously forgot. All the rest of the code functions as it did before, this last commit is just some of the ground work for refactoring.
This also includes the polygons with only one point each: The original dxf program must have "thought" of representing some parts as 1-point polygons, but do we need that in the QET element? I didn't find anything missing from the example!
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.
My knowledge of DXF is poor, but as I see it, many commercial programs, for example, export single circles as multiple splines, which can never become a space-saving circle or ellipse again when converting. Unless you rework the element in the element editor by hand
On the contrary:
In the dxf and therefore also in the resulting QET element, there are very often polygons that lie directly on top of each other, but which are not recognizable as individual graphic elements.
Nowadays, this is often due to the fact that devices are no longer made from several 2D drawings, but are created directly as 3D models. A 2D dxf drawing is then made from this, which accordingly also contains many hidden lines that inflate the resulting QET element, but do not provide any additional information.
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.
plc-user could you share the original dxf file that created these single point polygons?
Macos arm64 dxf2elmt for test.
FYI it's only work in an terminal...
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.
In all dxf drawings I had to convert so far, the individual splines were not really long or complex. That's why I'm wondering whether we really need 100 segments in the corresponding polygon for each spline as a default setting for the conversion to QET elements?
I have tried a few files with different numbers of polygon segments and I think that 10 or 12 points should be enough for good results.
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.
Do we really need the full precision of up to 14 decimal places from dxf for use in QET elements?
For all graphical elements in the element editor, a maximum of two decimal places can be entered or edited and the graphical editor only allows changes in the tenths range. Therefore, in my opinion, it is completely sufficient to use a maximum of two decimal places in conversion programs for QET elements.
Completely agree, I can change the default behavior to round to 2 decimals of precision.
I also noticed that the converted element file contains polygons with a only one point! QET_ElementScaler filters them out, but should they not be eliminated from the element file in the first place?
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.
@vadoola:Do you think it's possible to solve this problem?
https://github.com/antonioaja/dxf2elmt/issues/2Do we still have to do ‘select all and make explode all’ and save again in a DXF program before using df2elmt?
Just an FYI I seem to have solved this. I haven't committed it yet, because the code is a bit crude and I want to clean it up first. Hopefully I will get around to it sometime this week.
@vadoola:Do you think it's possible to solve this problem?
https://github.com/antonioaja/dxf2elmt/issues/2Do we still have to do ‘select all and make explode all’ and save again in a DXF program before using df2elmt?
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.
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.
QElectroTech → Posts by vadoola
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.033 seconds (64% PHP - 36% DB) with 5 queries