Search options (Page 13 of 32)

Please read the names of attached files again, spotu:
Both files, that are attached have the same name and the same content!

Salut Laurent !

With the help of that shell script, all occurrences of more than x decimal places (default: 5) are searched for in all elements in the current directory.

This raises questions for me:
- Who knows this script?
- Who uses this script?
- Is it also available for win?

I have extended the call a little to only count the elements in official common collection.
With original setting of 5 or more decimals:

$ ./detect_elements_bad_coordinates.sh | awk -F ":" '{ print $1 }' | sort | uniq | wc -l
1190
$ 

search for 4 or more decimals:

$ ./detect_elements_bad_coordinates.sh | awk -F ":" '{ print $1 }' | sort | uniq | wc -l
2004
$ 

If I then know which files are affected: How do I fix them?
Should I really go through the file(s) by hand in a text editor and change the values? Or use the element editor to click on each graphical part to edit?
It would be much more practical if this were done automatically in the background by the software I use to create the graphics!

The decimal places are already limited to two in the element editor, don't we want to be consistent and write only two decimal places to the file?

Won't be possible, because you added the same file twice!

The dxf contains Blocks in Blocks in Blocks in.....
That's currently not supported by dxf2elmt, but developer is working on it!
Use CAD-Software, to "explode" all blocks.
Then dxf2elmt produces beautiful elements!

Ja, im Moment ist das leider so!

Und ich glaube, das steht auch nicht ganz oben auf der Prioritätenliste, wenn der Haupt-Entwickler wieder voll einsatzfähig ist.
Es besteht natürlich immer die Möglichkeit, jemanden zu finden, der C++ unter Qt programmieren kann und Spaß daran hat, an QElectroTech mitzuarbeiten! Vielleicht kennst Du jemanden, stefan.123? Oder vielleicht kannst Du selber teilnehmen?

Ich finde es immer sehr schade, wenn hier nach neuen supertollen Funktionen gefragt wird, aber scheinbar niemand bereit ist, sein/ihr Wissen und Können hier im Projekt einzubringen.

Ich bin hier auch ganz langsam angefangen und habe Fragen gestellt und inzwischen traue ich mich daran, bestehende Funktionen zu hinterfragen und bearbeiten! Und einige davon sind bereits in QET eingeflossen...

Das geht nicht gegen Dich, stefan.123!!!
Ich wollte das nur mal loswerden...

Gruß
  plc-user

I'm a little envious: I don't have 48 cores! 

Hello vadoola,

It's good that we agreed on the scaling after all! I knew there was a misunderstanding somewhere... but didn't see
Sometimes I have to read the documentation and comments in the source code several times, too: the language barrier (French, English, German, ...) is sometimes quite high and with sharp edges!

Take your time for the realization!
As we say in German: "Gut Ding braucht Weile!"
‘Good things take time!’

If you look at the “imperial” DXF from last week:
Which one matches the original sizes better?

I know that we won't be perfect with text-size, because for elements we have to round to integer numbers, but I think we should be as close to the original as possible!

Salut Laurent !

Thanks again, Laurent!
The Debian-Version is also working pretty good!

A few questions about "qet_tb_plugin":
As I understand correctly, the plugin may or even can only be started, when a project is loaded, correct?
"qet_tb_plugin" or "qet_tb_plugin.exe" is an executable file, right?
And:
Similar to dxf2elmt or QET_ElementScaler QET only starts the executable from known locations ... QET does not download python or source-code of the plugin, right?

If all three answers are "yes", some of the "spaghetti-code" in qetdiagrameditor.cpp can be simplified and "automated" similar to configDir() or dataDir().
Already making first attempts...

Hello vadoola,

Just to understand you correctly:
You think the calculation of the text size is correct if a text that fits well into a rectangle in the DXF is much bigger and no longer fits into the same rectangle in the converted element? And that's because it says somewhere that a px is not as big as a pt? Seriously?

Attached is another example to clarify what I mean:
A DXF file in which I have inserted an 11 mm high text into a field of about 12 mm. Next to it is the converted element file, where you can see that the text “11 mm” definitely does not fit into the same field. In addition, the element file in which I changed the text “11 mm” to the appropriate size “22” and moved it.
I am explicitly not talking about the text position here, as we both know that this does not yet fit: I'm talking about the text size!

Note:
I used dxf2elmt - sources from last weeks commit c3a5b2a.

Back to the topic: 

Hello Vadoola,

I'm not quite happy with the font sizes yet.
That's why I used Inkscape to create a drawing with different font sizes. When I realized that the fonts were exported as polygons into DXF, I used LibreCAD to add some MText in different sizes.
I then converted the DXF into an element and realized that the font sizes did not fit.
If we focus on the 20 mm font:
In LibreCAD (black background) it is good to see that both texts are the same size - I expect the same for the element.
In the element (white background), the polygon 20 mm are 40px high, but the 20 mm text has a font size of 57.
So there is still a factor of about 1.4 somewhere in there that doesn't belong.
I noticed something similar with the imperial DXF from your American compatriot.

Packed all files into attached zip.

Remark #1:
The Text-Positions ... 

Remark #2:
When saving the DXF from Inkscape, the bottom edge of the rectangle was lost somewhere. That shouldn't bother you!