If you would have used Forum-Search you would have found this thread:
https://qelectrotech.org/forum/viewtopi … 5541#p5541
Or other Threads pointing to QET_ElementScaler
You are not logged in. Please login or register.
QElectroTech → Posts by plc-user
If you would have used Forum-Search you would have found this thread:
https://qelectrotech.org/forum/viewtopi … 5541#p5541
Or other Threads pointing to QET_ElementScaler
The link works fine for me!
Do you have any speacial settings set in your browser?
Or maybe a browser-plugin prevents this site from loading?
I'm only on Linux, so I can't really help you with Win problems, but:
Neither program really needs to be "installed".
dxf2elmt is a command line software and is called like this:
dxf2elmt DXF-Drawing.dxf
A corresponding *.elmt file is then created.
DXFtoQET is a program with a graphical user interface and does not have an integrated installation program: This only needs to be copied to the "appropriate" location.
Ich gehe jede Wette ein, daß Du NICHT QET-Version 5.irgendwas hast!
Das ist die QT-Version, die drunter liegt oder mit der kompiliert wurde!
QET ist erst bei Version 0.10 in der Devel-Fraktion und 0.9 bei den stable-Releases.
Menü -> Hilfe -> ÜberQElectroTech
vgl. Bild im Anhang
Editieren kannst Du die Eigenschaft "Ort" im Diagramm-Editor, wenn Du das Bauteil markiert hast - siehe Bildschirmfoto.
Ah ... o.k. ... habe auch nicht daran gedacht, dass ich seit Jahren immer die aktuellsten Devel-Versionen benutze.
Deswegen ist es immer sinnvoll, bei Fehlern auch die Programm-Version mit anzugeben!
Das ist irgendwann in eine Version eingeflossen, daß man das eintragen kann.
Vielleicht versuchst Du es einfach mal mit einer aktuelleren Programmversion?
Der Einbauort kann ja nicht wirklich sinnvoll im Element selber definiert werden: Das weiß der Ersteller ja gar nicht!
Deswegen macht es meiner Meinung nach nur Sinn, das im Diagramm-Editor editierbar zu haben, wenn das Element benutzt wird.
Bitte nicht ein- und dasselbe Thema in mehreren Foren posten!
The doubt remains whether by doing so I am NOT modifying a string which could then create a bug...
Here's where my question lies, "be able to enlarge a character" some font sizes without altering the element sizes (while still keeping the same dimensions as the original title block (columns/rows/pixes) and sheet (A4).
Then obviously how to update the elements already inserted in the sheet.
You should extend the search text to the tag that precedes it. For example
font="Sans Serif,5
If you make the changes only in your project files (*.qet), all elements contained therein should be changed. The element collections are then not affected. Automatic reversion is not provided.
If you then want to keep those modified Elements, you can create a new collection for yourself and then also change the UUIDs like Laurent said.
But keep in mind: Have a backup of the project!
Fonts have been a problem with computer systems, for ages! Especially when it is supposed to look the same across operating systems and languages.
If you try to familiarise yourself with the subject, you will quickly find evidence that the terms "font" and "font family" are often confused!
As an example: "Sans Serif" is the description of a family of fonts that have no serifs. The actual font behind it depends on what the user has set for it on their system. The same applies to "MS Shell Dlg 2": It's a replacement-name for any font the user sets in the registry ... this can even be "Symbol" or "DingBats"!
And: The operating system supplier often sets different fonts depending on the country.
This of course makes it difficult for software developers and users to get a clear line so that it looks the same across operating systems and languages. This is particularly noticeable to users who are working on different systems.
When you search the forum for "font" and "size", you'll find tons of messages about this topic!
Leelo Tiz cnge eleent in fonction, you need to change for these elements akso the UID/
see my script bash linux
https://download.qelectrotech.org/qet/scripts/
You want to place free text in the diagram and want to set a background-color for the text?
Placing Text is possible ... see screenshot.
For the background-color you need to do a workaround with a colored rectangle placed behind the text. (see screenshot)
What's wrong with these, for example?
Sicher gibt es eine Forumssuche!
So macht OpenSource Spaß: Jeder gibt einen Teil seines Wissens / seiner Erfahrung dazu!
-----
This is how OpenSource is fun: Everyone contributes a part of their knowledge / experience!
Hast Du welche beigesteuert, die veröffentlicht werden dürfen?
Das geht nur im Element-Editor - im Diagramm-Editor geht das nicht.
-----
Cela n'est possible que dans l'éditeur d'éléments - ce n'est pas possible dans l'éditeur de diagrammes.
Given a directory structure with QET elements and the SVG images derived from them.
Here is a script that goes through this directory structure and links all subdirectories and SVG files.
The links of the SVG files point to the corresponding QET element.
#!/bin/bash
# to be able to process blanks in file names - remember original state:
OFS=$IFS
# set new:
IFS="
"
BaseDir="elemente"
for d in `find $BaseDir -type d | sort`; do
echo "processing directory $d"
# html-Header:
echo "<html><body>" > $d/index.html
# Unterverzeichnisse auflisten:
for sd in `find $d -maxdepth 1 -type d | sort`; do
if [[ "$d" == "$sd" ]] ; then
continue
fi
echo "sub-dir: $sd"
echo "<a href=\"`basename $sd`/index.html\">`basename $sd`</a><br>" >> $d/index.html
done
# SVG-Dateien auflisten:
for f in `find $d -maxdepth 1 -name "*.svg" | sort` ; do
echo "file: `basename $f`"
svgdatei=`basename $f`
elmtdatei="${svgdatei%.svg}.elmt"
echo "<a href=\"$elmtdatei\">${svgdatei%.svg}<br> <img src=\"$svgdatei\" /></a><br>" >> $d/index.html
done
# html-Footer:
echo "</body></html>" >> $d/index.html
echo ""
done
# blanks in filenames - back to original:
IFS=$OFS
# DONE!
@Laurent:
In the context of writing the script, I noticed, that a scaling-factor of 5.0 will be in many cases too much!
But I will implement your idea of including the scaling-factor to the script on github!
Just for the record:
diff --git a/sources/editor/graphicspart/partdynamictextfield.cpp b/sources/editor/graphicspart/partdynamictextfield.cpp
index bb261287c..311102742 100644
--- a/sources/editor/graphicspart/partdynamictextfield.cpp
+++ b/sources/editor/graphicspart/partdynamictextfield.cpp
@@ -176,6 +176,12 @@ void PartDynamicTextField::fromXml(const QDomElement &dom_elmt) {
font_.fromString(dom_elmt.attribute("font"));
setFont(font_);
}
+ else if (dom_elmt.hasAttribute("font_size")) {
+#if TODO_LIST
+#pragma message("@TODO plc-user: remove again, when elements are converted!")
+#endif
+ setFont(QETApp::dynamicTextsItemFont(dom_elmt.attribute("font_size", QString::number(9)).toInt()));
+ }
else {
#if TODO_LIST
#pragma message("@TODO remove in futur")
May I suggest to sort the list alphabetically?
So one can find (missing?) languages "at first sight":
lupdate -noobsolete qelectrotech.pro -ts lang/qet_{ar,be,ca,cs,da,de,el,en,es,fr,hr,hu,it,ja,mn,nb,nl,pl,pt,pt_br,ro,ru,sk,sl,sr,tr,uk,zh}.ts
Why do I use this key combination but it doesn't work?
Manchmal liegt es daran, welches Betriebssystem mit welchen Spracheinstellungen Du hast, ob Tastenkombinationen funktionieren, oder eben nicht.
Bei Dir scheint es der Fall zu sein.
Aber dafür gibt es ja immer noch den Knopf in der Werkzeugleiste.
-----------
Sometimes it depends on which operating system with which language settings you have whether key combinations work or not.
This seems to be the case for you.
But there is always the button in the toolbar.
Habe im Quellcode des Element-Editors eine Stelle gefunden, an der ich eingreifen kann, um auch die dynamischen Texte korrekt einlesen zu können, deren Schriftgröße mit dem Tag "font_size" gekennzeichnet sind (siehe BugTracker).
Mit der Version des Element-Editors habe ich nun alle Elemente, die mit einer Programmversion kleiner 0.8 erstellt wurden, in der aktuellen Version abgespeichert. Dabei habe ich die XRef-Elemente, bei denen Laurent mitgeholfen hat, nicht mehr angefasst!
Die etwa 4600 geänderten Elemente liegen nun vorerst nur in meinem Fork des Elemente-Repositories bei GitHub:
https://github.com/plc-user/qelectrotech-elements
Ich möchte nun alle Leser und Benutzer aufrufen, diese Elemente auszuprobieren und zu testen, ob "ihre" Elemente so aussehen und funktionieren, wie erwartet! Die Absicht war, nichts am Element zu ändern, aber man kann ja nie wissen.
Bitte gebt Rückmeldung in diesem Forum, damit wir "Altlasten" auch mal loswerden können. Zumindest bei den Dateiversionen der Elemente...
Danke im Voraus!
Und: Danke, Laurent, für Deine großartige Unterstützung!
now the same in English via Online-Translator:
I have found a place in the source code of the element editor where I can intervene in order to be able to correctly read in the dynamic texts for which the font size is marked with the "font_size" tag (see BugTracker).
With the version of the element editor, I have now saved all elements that were created with a program version smaller than 0.8 in the current version. I have not touched the XRef elements that Laurent helped with!
The approximately 4600 changed elements are currently only in my fork of the element repository at GitHub:
https://github.com/plc-user/qelectrotech-elements
I would now like to call on all readers and users to try out these elements and test whether "their" elements look and work as expected! The intention was not to change anything in the element, but you never know.
Please give feedback in this forum so that we can get rid of "old burdens". At least with the file versions of the elements...
Thanks in advance!
And: Thank you, Laurent, for your great support!
There are only "a few" elements with this combination of tags:
$ grep -R "dynamic_text" . | grep "font_size" | awk '{ print $1 }' | sort | uniq | wc -l
67
$
As written in BugReport, the bug must be there since several releases:
The ReadyToUse-Version from November 15th and even the 0.9 AppImage from January this year show the same effects. I can't go further in history. I guess it was when the tags of "dynamic_text" were re-worked...
EDIT:
It's not when editing the texts: Opening the file is all you have to do to see the bug.
Thanks, Laurent for the hints!
Just reverted the PRs #8 and #9
What do you think: Do we have the chance for a BugFix of this mal-function in Element-Editor?
Salut Laurent !
Unfortunately, I had to create a bug report for the element editor:
The font sizes of the "dynamic_text" of older file formats are not handled correctly since some programme versions (see BugTracker). I have tested with the current DEV version and the 0.9 AppImage for Linux.
When the bug has been fixed, I will of course reapply my scripts to the original elements! But how do we proceed until then? I don't yet have enough experience with GitHub to be able to revert the current changes myself.
Sorry for the bad news!
Having fewer different individual parts inside the QET-Elements helps with multiline-Text for SVG-converting, too!
Especially for text-parts! See attachment!
[Edit]:
Just uploaded sources and created a new beta-release of QET_ElementScaler for Debian Bookworm, win32 and win64 at GitHub:
https://github.com/plc-user/QET_ElementScaler
QElectroTech → Posts by plc-user
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.018 seconds (41% PHP - 59% DB) with 6 queries