You are not logged in. Please login or register.
QElectroTech → Import DXF → New .dxf to .elmt Conversion Program
macOS Apple silicon arm64 binary
dxf2elmt.zip 1.24 mb, 38 downloads since 2024-10-19
Interesting for check dxf convertion with new dxf2elmt new builds.
https://github.com/LibreDWG/libredwg/tr … /test-data
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.
AutoCAD Sample Files from autodesk.
These sample files apply to AutoCAD 2010 and later.
https://www.autodesk.com/support/techni … jrnQ9.html
AutoCAD Sample Files from autodesk.
These sample files apply to AutoCAD 2010 and later.
Hi Erik,
The dxf2elmt plugin does not support DWG, which is a closed format keurk ... and same fonctionaly than the dxf file, don'use dwg when you can..
To convert dwg to dxf see https://wiki.freecad.org/FreeCAD_and_DWG_Import/en
LibreDWG https://github.com/LibreDWG/libredwg
ODA File Converter https://www.opendesign.com/guestfiles/o … _converter
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.
Hello Vadoola!
Hallo plc-user!
I just upgraded my git local repository of code, use git pull and cargo update and cargo build --release and now I saw all time popup error even if DXF convertion working... it is for debug?
[src/qelmt/mod.rs:70:9] view_pt = Point {
x: 0.0,
y: 0.0,
z: 0.0,
}
[src/qelmt/mod.rs:72:9] view_ht = 1.0
[src/qelmt/mod.rs:73:9] drw.header.insertion_base.clone() = Point {
x: 0.0,
y: 0.0,
z: 0.0,
}
[src/qelmt/mod.rs:74:9] drw.header.minimum_drawing_extents.clone() = Point {
x: 1e20,
y: 1e20,
z: 1e20,
}
[src/qelmt/mod.rs:75:9] drw.header.maximum_drawing_extents.clone() = Point {
x: -1e20,
y: -1e20,
z: -1e20,
}
[src/qelmt/mod.rs:78:9] view = []
[src/qelmt/mod.rs:80:9] drw.header.default_drawing_units = Millimeters
Other
[src/qelmt/mod.rs:70:9] view_pt = Point {
x: 0.0,
y: 0.0,
z: 0.0,
}
[src/qelmt/mod.rs:72:9] view_ht = 1.0
[src/qelmt/mod.rs:73:9] drw.header.insertion_base.clone() = Point {
x: 0.0,
y: 0.0,
z: 0.0,
}
[src/qelmt/mod.rs:74:9] drw.header.minimum_drawing_extents.clone() = Point {
x: 0.0,
y: 0.0,
z: 0.0,
}
[src/qelmt/mod.rs:75:9] drw.header.maximum_drawing_extents.clone() = Point {
x: 1.683250261529439,
y: 3.8125,
z: 0.0,
}
[src/qelmt/mod.rs:78:9] view = []
[src/qelmt/mod.rs:80:9] drw.header.default_drawing_units = Unitless
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?
Hello Vadoola,
I 'm sorry .... I tried it last week and not saw you have updated repository since.
Git info informs me I have commit 886a57331d1b7cea045e32a8741ed4ee57473f50
"Some more work on Scaling Elements"
Edit: I have updated now but, is late for me, I will try it tomorow to try new version.
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.
I understand, FYI in the past we use also SVN, and moved to GIT ~ in 2019 on our host, and after on github since tuxfamily free/libre hoster 's probems.
And when we had to find a new host this time, and need to pay... we decided with Xavier, the creator of QET, to use only the github repository and not to put the GIT repository on the server.
From our experience, some pull requests made on the github didn't go through very well on our git hosted.
https://qelectrotech.org/forum/viewtopic.php?id=1427
https://qelectrotech.org/forum/viewtopic.php?id=2533
Hello Vadoola!
Salut Laurent !
That's a great step forward, 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.
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.
This is how it looks now (formatted by hand!)
<dynamic_text x="35.12" y="-11.14" z="0" rotation="0"
uuid="{51347e64-514a-47dc-8c7f-aa180de58afd}"
font="Arial Narrow"
Halignment="AlignHCenter" Valignment="AlignVCenter"
text_from="UserText" frame="false" text_width="-1" color="#000000">
<text>\C7;\fArial|b0|i0|;\H0.030335398390889;All Connectors
are Located
Under Gullwing
Covers</text>
</dynamic_text>When I look at the texts in the converted element, I think that this would be correct for the text, font and font height:
<dynamic_text x="35.12" y="-11.14" z="0" rotation="0"
uuid="{51347e64-514a-47dc-8c7f-aa180de58afd}"
font="Arial,3"
Halignment="AlignHCenter" Valignment="AlignVCenter"
text_from="UserText" frame="false" text_width="-1" color="#000000">
<text>All Connectors
are Located
Under Gullwing
Covers</text>
</dynamic_text>The font-size of "3" in this example has of course to be set to the correct value: I chose a reasonable value here.
parts.zip 210.64 kb, 7 downloads since 2024-12-18
Hallo plc-user
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.
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.
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.
Hello Vadoola!
Hallo plc-user!
@Vadoola: Don't rely too much on the default folio dimensions columns 17 X60 pixels and Rows 8 X 80 pixels...
Personally, I use 24X60 pixels by 12X80 pixels for my titleBlocks, so the elements are smaller than on a default folio.
https://qelectrotech.org/forum/viewtopi … 048#p17048
I'll have to find plc-user's messages about the dimensions of the thumbnails, like this.
https://qelectrotech.org/forum/viewtopi … 393#p17393
Hello vadoola!
Salut Laurent !
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.
As I already wrote several times in this forum:
QET is primarily a software to draw schematic diagrams.
QET is no substitute for CAD software like LibreCAD, AutoCAD or so.
The only dimension QET "knows" is px!
These number of px can be set by every user individually for height/width of a folio.
A folio itself has no direct connection to a papersize – it can be printed to any papersize, users have a printer for.
So in my opinion we should NOT use a specific size of paper for the scaling of elements!
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.
We already have a wild mixture of scaling-factors with front-views: Please don't add another!
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!
Salut Laurent,
Hallo plc-user,
I'll have to find plc-user's messages about the dimensions of the thumbnails, like this.
https://qelectrotech.org/forum/viewtopi … 393#p17393
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 px1 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.
Hello vadoola!
About the texts / fontsThat 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.
Hello Vadoola!
Salut Laurent !
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 ...
It would of course be a great help to see such a unitless file in order to be able to judge how we should deal with it.
But if there are no units, there is nothing you can do but assume pixels as the unit. Perhaps a factor of 10, 100, etc. would make sense if it turns out that the structures would otherwise be too small? You can only estimate the factor if you have seen a few examples...
QElectroTech → Import DXF → New .dxf to .elmt Conversion Program
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.030 seconds (20% PHP - 80% DB) with 11 queries