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
You are not logged in. Please login or register.
QElectroTech → Posts by plc-user
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
Ok!
Then: Let's publish the changes!
Salut Laurent,
ok ... understood and changed that for elements that only have one "dynamic_text" like the samples above.
What about the elements that have a contact with numbers like this one with some more "dynamic_text"?
<definition hotspot_y="26" width="30" version="0.100.0" type="element" height="50" link_type="next_report" hotspot_x="17">
<uuid uuid="{8e4fac98-05b1-4f6a-be61-8559b7b5789a}"/>
<names>
<name lang="it">Contatto NC</name>
<name lang="cs">Rozpínací kontakt NC</name>
<name lang="fr">Contact NC</name>
<name lang="nl">ref volgend complex contact (NC)</name>
<name lang="es">Contacto NC</name>
<name lang="pl">Zestyk rozwierny</name>
<name lang="en">complex contact NC</name>
</names>
<informations>autor: paul deelenlicencja: zobacz http://qelectrotech.org/wiki/doc/elements_license</informations>
<description>
<dynamic_text font="Sans Serif,4,-1,5,25,0,0,0,0,0" text_width="-1" keep_visual_rotation="false" frame="false" Halignment="AlignLeft" x="-23" rotation="0" text_from="UserText" z="1" uuid="{5ede35ec-f568-47de-9ee3-5cb8ae7ff744}" Valignment="AlignTop" y="8">
<text>12</text>
</dynamic_text>
<dynamic_text font="Sans Serif,5,-1,5,50,0,0,0,0,0" text_width="-1" keep_visual_rotation="false" frame="false" Halignment="AlignLeft" x="-23" rotation="0" text_from="UserText" z="2" uuid="{06a8d219-aa9f-4133-b285-c276975af1f5}" Valignment="AlignTop" y="-25.5">
<text>11</text>
</dynamic_text>
<polygon y3="-10" x2="-10" x1="-10" y2="10" style="line-style:normal;line-weight:normal;filling:none;color:black" antialias="true" y1="20" closed="false" x3="-4"/>
<line x2="-3" x1="-10" y2="-9" style="line-style:normal;line-weight:normal;filling:none;color:black" length2="1.5" antialias="false" y1="-9" length1="1.5" end2="none" end1="none"/>
<line x2="-10" x1="-10" y2="-9" style="line-style:normal;line-weight:normal;filling:none;color:black" length2="1.5" antialias="false" y1="-20" length1="1.5" end2="none" end1="none"/>
<dynamic_text font="Sans Serif,10,-1,5,50,0,0,0,0,0" text_width="-1" keep_visual_rotation="false" frame="false" Halignment="AlignLeft" x="-2" rotation="0" text_from="ElementInfo" z="6" uuid="{30a611c8-4454-4c09-95dd-8706dab6053e}" Valignment="AlignTop" y="-12.5">
<text>/</text>
<info_name>label</info_name>
</dynamic_text>
<terminal x="-10" type="Generic" uuid="{5746597c-3494-4922-9747-b8d1512da17c}" orientation="n" name="" y="-20"/>
<terminal x="-10" name="" type="Generic" uuid="{3a8a0eed-90d6-4948-a59f-96dafaa4dc31}" orientation="s" y="20"/>
</description>
</definition>
Do we need to change this from text_from="UserText" to text_from="ElementInfo", too ?
source of text: element information
/
Label
Done!
Ok ... the hacks with text-editor seem to work!
All Elements which contained "input" are updated with current QET-Element-Editor (and Text-Editor)!
PullRequest is on the way!
these elements serve as folio reports and allow you to link two different components, (...).
Don't get me wrong: I want to keep these elements!
All I want is to get rid of those "input" inside the elements and replace them with "dynamic_text" to have elements that were created using the current version of element-editor!
In the attachment you find a *.tar.gz with updated elements.
Would someone who uses them regularly please test if they work as expected?
If so, I'll create a PullRequest with all 4089 updated Elements.
Salut Laurent !
I searched the elements-directory and found 4089 Elements with "input", which was the old element-part of actual "dynamic_text".
As explained above: Then I opened all of them in Element-Editor and saved them again in the actual file-format.
Some of the files represent References, which caused errors when trying to save: see screenshot in attachment.
I also attached these files in a *.tar.gz.
I might create a PullRequest at GitHub to update the QET-Elements which could be saved without errors.
Do you think I should, Laurent? Would be a bigger change ...
Best regards
plc-user
Texts are there but with font-size=0
The tags for font-size in "input" and "dynamic_text" are different: Fixed that in source-code of QET_ElementScaler.
[Edit]:
Just as a question:
Do we have the option of using the element editor with command line parameters?
"Open" in the old file format and "Save to a file" in the current file format would be sufficient.
A "big hammer" isn't always the best tool:
I re-worked the sources of entity-converter to be a bit "milder".
Now letters with accents and unicode should (!) work again.
First version with translating html-entities is available as Source on github.
It's the first "brute-force"-version that's far from perfect.
If someone knows if I can use the pugi-internal function "text_output_escaped" for this, please let me know!
In this context I corrected an error with text-size of "dynamic_text".
Salut Laurent !
Thank you for testing that function!
You found an element that contains text with characters that have to be converted to a HTML-Entity. In this case: "&"
That's one thing that is not covered, yet.
I'm working on it!
In another context I recommended the "Eaton Schaltungsbuch" formerly known as "Klöckner-Möller-Schaltungsbuch"
https://qelectrotech.org/forum/viewtopi … 215#p19215
There you find on PDF-page 504 that it should be EN IEC 81346-2 (see attachment)
On page 10-3 there are some examples from that standard.
But I don't know if QET follows this standard 1:1 ...
Guten Morgen!
Sollten wir konsequenterweise nicht auch für die Schriftfelder eine Firmensammlung einführen?
Ich habe da mal was vorbereitet...
Gruß
plc-user
-----------
Good morning!
Shouldn't we also introduce a company collection for the title blocks?
I have prepared something...
Kind regards
plc-user
-----------
Bonjour à tous !
Ne devrions-nous pas, en toute logique, introduire une collection d'entreprises pour les cartouches ?
J'ai préparé quelque chose à ce sujet...
Salutations amicales
plc-user
That's a fact: Drawings are not centered on PDF-page.
See also here:
https://qelectrotech.org/forum/viewtopi … 437#p18437
EDIT:
You can "play" with the settings for the rows and cols for your folio(s)
and (at least on Linux-Systems) you can enter margins for PDF-export.
@rvamerongen:
Als je al Nederlandse teksten invoert, is het geen grote moeite om de andere ook te veranderen.
Ik heb een paar andere Nederlandse teksten toegevoegd - misschien valt het je op...
PullRequest #276 with updated texts is placed.
@Laurent:
[Edited]
Can it be that there went something wrong with creating and "compiling" TS-files at your side?
In my understanding you wanted to create TS- and QM-Files? Please correct me, if I'm wrong!
The translated texts are available in the German TS-File in the PR.
The QM-File for English in git-repository is different from my locally "compiled" file.
Or should I create a PR with "my" files? You decide!
Best regards
plc-user
Do you mean upper / lower case?
Salut Laurent!
1st problem, the company collection replaces the custom collection, you just need to define a new directory for the company collection in the gui.
Fixed with Pull-Request #275
Best regards
plc-user
QElectroTech → Posts by plc-user
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.028 seconds (28% PHP - 72% DB) with 5 queries