Search options (Page 1 of 3)

Salut Christophe,

Version 0.4.0 is not the latest version. The latest version is what Laurent linked above and is version 0.5.1.

I actually just noticed that I forgot to bump the version in the cargo.toml file, so even though it is version 0.5.1, if you run dxf2elmt --version it will say it's version 0.5.0. There were some large changes and new features between 0.4.0 and 0.5.0 so it's possible the file that is failing in 0.4.0 will work in 0.5.0.

I'm not seeing any linked dxf files, and a quick glance shows several versions of KNX MDT modules. If it still fails to convert correctly once you download 0.5.1 can you link to the dxf files so I can find out where it's failing and try to fix it?

Thanks

Salut Laurent,

I don't have the binaries up on the release page yet, but I've fixed the bug that was causing you issues running it from QElectrotech on your Mac.

If it can it creates the log file, but if it fails, it just skips it and logs to stderr.

https://github.com/Vadoola/dxf2elmt/releases/tag/v0.5.1

Yeah, I have no experience or familiarity with Github CI. I've been trying to hobble something together by copying how some others have done it, and have been completely unsuccessful. I probably need to set aside some time to sit down and learn it properly. The hope of course is that I can get it set up, and when a release is made CI will generate the binaries and attach them to the release.

For this release it will probably be faster and easier to just manually create them myself and get them uploaded.

The problem was that dxf2elmt didn't yet support nested blocks. I have a separate branch where I'm working on this. I actually had it working for this specific drawing, but I have another drawing with more deeply nested blocks and different scaling as they are nested. So far my attempts to get this working either correctly import one drawing or the other. I need to spend a bit more time to get it all working more consistently.

Thanks I'll take a look at it.

I've never heard of IS0 3O98, it looks like it's mostly a European thing, but it looks similar to other fonts I've seen used by AutoCad even outside of the Europe. I agree based on that screenshot you sent it does look a lot closer to what is being used by CAD that the Sans Serif font. Setting the default to "osifont" should be pretty straight forward. I'll see if I can do it tonight.

Maybe that's what I was remembering that it was documented but wasn't quite right because the number of comma-seperated entries didn't match.

I looked into the Qt5 code to make sure the font string in dxf2elmt was being generated the same. I never looked at the Qt6 code since it wasn't relevant at the time. Looking at the doc for QFont::toString() in Qt5 and Qt6, it's identical, so I'm not really sure what the difference is or why it would have changed in the code. I'm just assuming the Wireshark issue is correct and there was a change however, and it might effect a future Qt6 version of QET, so it's good to be aware of it.

Good to know that we do, it was completely accidental, I mostly just stuck with the same general ordering of attributes Antonio was using in the original version. I'll try to make sure it stay's in sync with what QET_ElementScaler does.

Blocks are currently supported. The way I wrote it I would have thought nested blocks would be supported, but I have not actually tested that yet.

I'll have to do some testing with your file and see why it's not working.

If it is due to nested blocks, what plc-user suggested: opening it in some CAD software and doing an explode on the blocks should work as a temporary solution until I can update the software.

I'm taking a closer look now that I'm on my lunch break, and it looks like I'm completely wrong about QET saying the font is in pt's. Nowhere does it say that, it simply refers to it as size. It's just so common for font to be stored as pt's instead of pixels I must have just assumed size meant font points instead of pixels. I clearly made a mistake here, downside of squeezing in time when I can even if that means I'm a bit distracted or tired. I'll try and find some time to get the code updated to scale the text correctly.

Hallo plc-user

I think I worded things in a way that did not translate properly for someone who is not a native English speaker. Sorry about that, I will try and word things better to make it more clear.

The current code is my first attempt and properly handling the text sizing, and text scaling over what Antonio had with just a fixed 12pt font. I based the conversion of the text size from real world units (which the text height is stored as in dxf) to font points using the defined definition of 1pt = 1/72 inch. In the couple of drawings I tested this scaling looked OK, but I knew it needed more testing and verification. I checked it in because it was already better than what was there. Perhaps I need to do a better job and work at some of these features in branches instead of on master so people don't think the checked in code is fully functional, however you testing against it and provided these files is very useful feedback for me to fix problems.

When you brought this up and provided the Schriftgroessen file I checked against some online calculators converting mm to pt to verify that I had done the math correctly in my code. Based on the conversion of 1pt = 1/72 inch, I did do the match correctly in my code, but this conversion factor clearly does not provide good results, after testing against some more files.

So the question is what conversion factor do I need to use? In the Schriftgoessen file you provided, if I had assumed that 1mm  = 1pt and then scaled it with the mm->px conversion of 2x, that actually would have been more accurate. It looks like it actually should be converted by a factor of 2.1, but 2 would have been closer than 2.8 used based on the mm->pt conversion I used. What I need to figure out is that roughly 2x height to pt conversion in the Schriftgroessen file something that could be valid or just coincidence in the factors similar?

Perhaps a better method here is assume that 1 unit (based on the file, mm, inches etc) is equal to 1pt and then scale based on the 1mm = 2px, perhaps I should always assume 1mm = 1pt, and then scale. I'm not really sure, I'll need to do more testing to try and narrow down what the right scaling factor might be, and need to make sure I'm testing against multiple units.

I think the next step for me to do is create a handful of files along the lines of Schriftgroessen but in several units like inches, ft, cm, etc and do some testing to try and narrow down a more accurate scaling factor.

Hopefully that makes things a bit more clear.

Hallo plc-user,

I can double check, but I believe this extra scaling factor for the imperial unit drawing was fixed in the last commit.

The scaling for the font is handled separately from the rest of the drawing. This is because dxf stores text height in whatever unit the drawing is in (ie mm, inches, etc) and QET uses your stand font points. A font point is defined as 1pt = 1/72 inches, which comes out to 1pt = 0.3528mm.

Based on this conversion the values that are being generated are "correct", because text height in mm would be multiplied by a factor of roughly 2.83. instead of the 2 used to convert mm to pixels.

I checked a couple of online unit conversion calculators to verify my math and 20mm comes out to 56.692913386pt font, rounded to 57 in the element.

You are right though that this clearly isn't correct in the element file. Doing a quick hacky test of modifying the text element font size to try and match the polygon size, it looks like the factor in your sample file should be 2.1. (for the 20mm text, a font size of 42pts).  It's not clear to me where this 2.1 comes from...but it is close to the 2px per mm we use in the conversion of this drawing. Perhaps multiplying the text height in real world units by the same as the rest of the drawing instead of "properly" converting between font points and real world units would be better? I'll need to try and do more testing and see what I can come up with, and test it against some other drawings.