Search options (Page 1 of 3)

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.

Lots to respond to...

The QET Forums, either this thread or creating a new one, are probably the best place for this. I do use Github Issues (https://github.com/Vadoola/dxf2elmt/issues) for tracking problems or enhancements etc., but if you make a post here, there can be a bit more discussion about it and I can make an Issue on Github, you are more then welcome to make a Github Issue as well though.

Thanks for the spreadsheet, I can take a look at it. The scaling should be in there already, but only recently and includes all the units supported by DXF. The code can be seen here: https://github.com/Vadoola/dxf2elmt/blo … od.rs#L213. Perhaps you grabbed a slightly older version of the conversion utility, because I only checked in that code a few days ago.

Now worries, I to am 'Murican, but have been living in New Zealand (where my wife is from) for a while now, that's why I'm late to the party here, I was asleep for most of this conversation.

Yeah there is still quite a bit of work to do on the text but I'm slowly chipping away at it.
There are multiple text types in DXF
    * ArcAlignedText
    * MText
    * RText
    * Text
Right now Text should be somewhat well supported, but there are issues. MText has some very early and crude support, and the other two have no support. Just looking at the screenshot you shared (without having looked at the DXF yet) I'm guessing these are regular "Text" objects.

A font size of 1298 certainly seems wrong, I'll have to do some testing on that file to see what's going on. The DXF actually stores font height in drawing units, so if the drawing defaults to inches, the text height will be stored in inches not font points. I convert between real world units and font points at the code Laurent linked above and round it to a whole number. The conversion is based on the definition of a PostScript font point where 1pt is defined as 1/72 of an inch, and in my testing so far this seems to work well.

It's certainly possible and hard to know. I'll take a closer look at the dxf and see what I can find, it might be a couple of days before I can get to it though.

Yeah I will probably need to use both to try and figure it out. That DXF file seems to be a bit all over the place. I opened it up in QCad, and in the details is the said the drawing was Unitless, the Paper was in millimeters, and the hatching was in imperial units....

That same section of Terminal Block according to QCad was 1.09, I'm not sure where that number is coming from, and don't see any obvious way to make it line up with the 18.19mm you got from FreeCad

To me it looks like it might be a Distech ECY-DI16. I found this PDF (https://docs-be.distech-controls.com/bu … les_SP.pdf) with some dimensions from various parts in that series, but none of the drawings show the terminal blocks like in the dxf. Going off the width of the main module and not the terminal blocks, that PDF gives 2.95 inches / 74.99mm. QCad is giving me "1.51983129"...I really have no clue where that is coming from.

So I went ahead and installed FreeCad, and measuring that same base part of the dxf file I got 39.03mm....which once again no obvious way that lines up to 74.99mm. It seems if no units are defined perhaps the CAD program just make a best guess, and each one does that differently?

Salut Laurent,
Hallo plc-user,

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.

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.