Search options (Page 2 of 3)

With the logic I added to check for circle shaped polygons and converting them to QET ellipses hopefully this will be less of an issue, but I know there is more work to be done here.

Good question, and I'm not sure what a good default value would be. I didn't parse through all the QET Elements, but I looked at the Ladder Diagram elements, and they are 20px high (if I recall this was a couple of days ago).  So that's probably a good absolute minimum size for an element. However I doubt people will be importing dxf's of tiny simple drawings like a ladder diagram coil or contact. This would probably be mostly used for importing drawings of real life objects. I'm wondering if something like if it's under 20px high, we multiply it by 10? I feel like we might need to find some more sample files to test against. There may be enough differences here that it's not easy to come up with a good default.

I also just pushed another commit tonight that has some early stage work for properly scaling the fonts based on the size in the dxf file. From my testing so far there are some issues with the placement of the text due to a bigger boundary box in QET than what I believe the dxf is expecting, but it's an improvement over what was there before.

Thanks for looking into this. It looks like INSUNIT (https://help.autodesk.com/view/ACD/2025 … F55A2B4FD8) is for trying to match the scaling between a block and the drawing its inserted into. Gives me a good place to start looking further.

Hallo plc-user

That calculation is based on trying to map the real world dimensions to pixels based on an A4 Sheet of paper using the standard QET Template. The standard QET Template I believe is 700px high (including the title block) and landscape, so that would come out to 700/210mm = 3⅓px per mm, which comes out to 200x700px, and printed on an A4 sheet of paper should be roughly the real world dimensions of 60x210mm. That is obviously a very large item on an A4 sheet of paper, real world dimensions in landscape it's about 30% of the height, and 70% of the width, so perhaps this isn't the best way to do it. I am open to suggestions or thoughts on how better to map the real world dimensions to useful pixels for the elements.

In the original code from Antonio there were a handful of things that were hard coded, whether the polygon was open or closed for example was just hard coded initially to false, then true, instead of reading it from the dxf. I'm slowly going through and trying to clean these up and grab the information from the dxf where it exists and use it appropriately. The Fonts for the text is one of these, he just had a hard coded "Arial Normal" in there with no font sizing regardless of what was in the DXF. This is the next thing I plan on tackling is reading in this information correctly and using it.

Hi Laurent, plc-user

I know I disappeared for a while, had some family issues to deal with.

The past few days I've been back at it. I know there are some bugs, but I've been working on 2 features, and if you would be able to do some testing that would be helpful.

The new features are

• Scaling: I wasn't sure the best way to convert from real world units (inches, cm, etc) to the pixels used by QET, I decided to assume the default QET template and column/row layout would map to an A4 sheet of paper and used that to map between pixels and real world units. I'm not saying it's the best option, but in my testing so far seems to work fine. If you have any other suggestions on how to do this, let me know.

• Ellipse Conversion: The program now tests Polylines, and LwPolylines to test how close to a circle they are, and converts them to a QET Ellipse element if it's pretty circular, instead of a multi-segmented polygon. This would prevent one of the issues that plc-user brought up when suggesting the scaling, due to some "circles" looking bad when dropped down to 2 units of precision. There are some limitations, such as this works on single polylines that make up a rough circle, but I have some DXFs where there are "circles" made of several polylines, those won't get converted by the current code

In a few of my tests I've noticed some issues with Text, and text scaling, I'm going to look into those and try to resolve them next.

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?

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.

Hallo plc-user

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

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.

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.

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.

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 Laurent

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.

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.