1

(142 replies, posted in Import DXF)

Salut Laurent,
Hallo plc-user,

scorpio810 wrote:

I'll have to find plc-user's messages about the dimensions of the thumbnails, like this.
https://qelectrotech.org/forum/viewtopi … 393#p17393

plc-user wrote:

As I suggested several times we should use a front-view-scaling where the user can see the real size at first sight or where he/she can calculate the real size by using a simple integer factor:
1 mm <-> 2 px

1 px is also the smallest step size, a QET-Element can be moved in diagram-editor. So then we could "move" the elements by 1 px = 1/2 millimeter in real-life.

Thanks going through these discussions was a good read. Either I hadn't seen these or just forgot about them, when I got back and started working on this. I agree the 1 mm <-> 2 px ratio seems like it would work well, I'll make this change and do some testing on it.

Another question is if I have a dxf that is "unit less" should I do any scaling at all or just assume it's in pixels. I don't recall which drawing it was at the moment, I'll have to try and go back to find it, but I had one drawing which was unit less and with no scaling it was quite small, but with no dimensions at all it's hard to make any assumptions and give a reasonable output that would work across all drawings. So perhaps it's better to just leave them as is, and if the user needs to scale using QET_ElementScaler they do.


plc-user wrote:

Hello vadoola!
About the texts / fonts

That wasn't meant as a negative criticism: just a remark that this is the case.
It is clear to me in particular that there is still a lot of work to be done to integrate the texts correctly into the element. You will have "a lot of fun” with the text position, because it is not directly on the baseline of the first letter, but on a bounding box that is specified by qt, but not well described...

A difference to many other software: QET can only handle font-sizes which are integer numbers!

No worries I didn't interpret it as negative criticism. I was just trying to point out myself that right now nothing is really handled at all for fonts and there is a lot of work there.

In another forum post there was a bug report about the text ending up in the wrong location. I looked into it and found out why, but fixing it wasn't so straight forward. Essentially per the DXF spec, if text isn't using the default alignment of Top and Left, you need to use the "Second alignment points" and then calculate the size of the text in the appropriate font, to get the x and y coordinates. Reading in these second alignment points from the DXF is easy, but calculating the text dimensions in the appropriate font not so much.

I already started doing a bit of work on the font handling stuff last night. There is a lot of work to do there, but hopefully I can start getting some small improvements going.

2

(142 replies, posted in Import DXF)

Hallo plc-user

plc-user wrote:

Hello Vadoola!
It looks very good, but unfortunately I have to say that the dimensions are not yet right. There's a factor of 10/3 in there somewhere with the part I used. The attached part has the dimensions 60 x 210 mm, but the resulting element is 200 x 700 px.

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.


plc-user wrote:

And when I look at the texts that come out of a previously used example (05DI-AD16DIX-10.dxf): There the font is not correct yet and the font height is not set either, so QET uses the default size 9 when opened.

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.

3

(142 replies, posted in Import DXF)

Hello Laurent,

Strange, that looks like debugging info I had in there while I was testing, but I just checked the last commit (fb09197) and I had removed it before committing.

Are you sure you grabbed the latest commit?

The other possibility is I screwed something up, the last time I worked on a (non-plc) project as a team was in C++ but probably 12+ years ago now and we were using SVN. All my experience with Git is as a solo developer, and I have a tendency to just work off the main branch. I know it's not best habits and have been trying to learn better git technique, so I was working on these features in a different branch and then merged them. Perhaps I didn't merge them correctly, and you aren't seeing the latest code?

4

(142 replies, posted in Import DXF)

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.

5

(142 replies, posted in Import DXF)

scorpio810 wrote:

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.

6

(142 replies, posted in Import DXF)

scorpio810 wrote:

I've noticed that many more DXF files are now being converted,
whereas previously they would generate an error and can't be converted.... nomicons/wink

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?

7

(142 replies, posted in Import DXF)

scorpio810 wrote:

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

8

(142 replies, posted in Import DXF)

scorpio810 wrote:

@vadoola: FYI https://qelectrotech.org/forum/viewtopi … 496#p20496
https://github.com/ixmilia/dxf-rs/issues/46

You 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.

9

(142 replies, posted in Import DXF)

Hello Laurent and plc-user,

plc-user wrote:

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.

10

(142 replies, posted in Import DXF)

Hallo plc-user

plc-user wrote:

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

plc-user wrote:

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.

plc-user wrote:

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.

12

(142 replies, posted in Import DXF)

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.

13

(142 replies, posted in Import DXF)

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"

14

(142 replies, posted in Import DXF)

plc-user wrote:

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.

15

(142 replies, posted in Import DXF)

scorpio810 wrote:

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.

kondareddy232 wrote:

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.

17

(142 replies, posted in Import DXF)

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.

18

(10 replies, posted in Import DXF)

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.

19

(142 replies, posted in Import DXF)

plc-user wrote:

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.

20

(142 replies, posted in Import DXF)

Hello Laurent

scorpio810 wrote:

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.


scorpio810 wrote:

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.

21

(142 replies, posted in Import DXF)

plc-user wrote:

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.

plc-user wrote:

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

plc-user wrote:

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.

22

(142 replies, posted in Import DXF)

plc-user could you share the original dxf file that created these single point polygons?

23

(142 replies, posted in Import DXF)

scorpio810 wrote:

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.

plc-user wrote:

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.

plc-user wrote:

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.

plc-user wrote:

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.

24

(142 replies, posted in Import DXF)

scorpio810 wrote:

@vadoola:Do you think it's possible to solve this problem?
https://github.com/antonioaja/dxf2elmt/issues/2

Do 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.

25

(142 replies, posted in Import DXF)

scorpio810 wrote:

@vadoola:Do you think it's possible to solve this problem?
https://github.com/antonioaja/dxf2elmt/issues/2

Do 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.