QET-Element to SVG (Page 1 of 4)

Hallo Plc-user,

wow it's very great news, thank you so much again Plc-user for your works. \o/

See history of HTM color in this topic:
https://qelectrotech.org/forum/viewtopic.php?id=1245
And the first patch
https://qelectrotech.org/forum/viewtopi … 61&p=3

Maybe a possible changes in this PR ..?
https://github.com/qelectrotech/qelectr … 88a0721f86

Best regards,
Laurent

Salut Laurent!

With your explanations and hints from the older posts: I think we can drop the topic "color" for now. Especially because the translation-table now exists for me and seems to work properly.

As you already mentioned in the other thread, the texts are the particular challenge when converting to SVG!

Not only are the zero points for horizontal text different for "text elements" and "dynamic text", but this has a particular effect when the text is rotated. The font size and rotation-angle must then also be taken into account for the new position. In the attached screenshot you can see at the top the SVG with text and blue rect with the same values for x and y. In the lower part you see Element-Editor with a dynamic text, it's bounding box in dotted line and a rect with the same x- and y-values. In both cases x- and y-values for ELMT and SVG are the same (can be seen with rects)!

The "puzzle" continues if the dynamic texts are aligned differently horizontally and vertically...

Perhaps you have a hint for me where I can read, for example, how the border boxes of the various text elements behave depending on the font size? They are also different in size for text and dynamic text.

The font is a completely different topic: Is it perhaps possible to limit ourselves to a few generic font families instead of trying to support all the fonts that the various systems have to offer? As has already been criticized in many posts here in the forum, the texts behave differently depending on which operating system the file is opened on.

I would therefore suggest that we limit ourselves to generic font families (e.g. SansSerif, Serif, Monospace). Since we can process Unicode, I don't think we need a super-special font that is only available on system xyz. I will at least try to limit myself here for now.

But the most important thing for now would be the positioning of the different texts. Maybe you know where I can read in QET-Sourcecode or QT-Documentation where I can find hints about that?

Best regards
  plc-user

Hello Plc-user,
I'm happy to read you are currently working on an elmt to svg converter, and wow very very good job.

About the color : like you say, you can drop it for now.

About text : For historical reason (and bad choices I made), how the texts are managed in the elmt file is a mess.
With the links Laurent give, you can see there is several way how the position of the text are saved, and no one are good in sense of svg.

If you read PartText.cpp, the function toXml, you can see the position x and y is the position of graphicsItem of the text but not the text itself (in the same class read the function void PartText::adjustItemPosition(int new_block_count)).

And in the class PartDynamicTextField it's approximately the same thing.

In svg, the position of the text is the base line https://developer.mozilla.org/en-US/doc … ement/text and the base line is bottom left of the text (like you say in previous post)
So to resume the situation, it will be very difficult for you to convert the "qet" position to "svg" position, withouse the baseline of the current used font. From my point of view try to approximate the position in first time.

One other thing, the text size with Qt (see QFont class info) can be pixel size of point size. Until some year we used default value (point size) and have no problem because QElectroTech was used in with screen with same dpi. But now there is a lot of screens with different dpi and the text are not displayed in same size from screen to another. This is why now (and if we had known that before, we would done it from the start) we use pixel size.
Point size => Same physical size one screen no matter the dpi.
Pixel size => Same pixel size on screen no matter the dpi.
Consider the font size are in pixel size even if it's was not true when the element was saved.

I probably forget some information don't hesitate to ask us.

I don't know if you are aware or not but in future (long ?) I plan to rewrite a large part of QElectroTech (To solve lot of problem, bad choice, base design, etc...) one point of this rewrite is to use true svg for the graphical aspect of element and not an ersatz of it.
May be when this time will come I will used your code for that (if you are ok).

some link about text in Qt

https://doc.qt.io/qt-5/qfont.html
https://doc.qt.io/qt-5/qfontinfo.html
https://doc.qt.io/qt-5/qfontmetricsf.html

Don't forget, we don't draw directly text in the folio, but draw text inside a QGraphicsItem and the position is the position of this item, not the baseline of the text.
https://doc.qt.io/qt-6/qgraphicsitem.html

Joshua

I don't know what lib you use to write your converter,
but if you use Qt, you probably can find the bottom left corner by create an instance of QFont and QFontMetric with the specified font read in the xml.
If not (Qt) I think you can easily find lib to achieve this job.

About the rotation of the text in svg, there is the attribute rotate but apply the rotation for each character of the text.
https://developer.mozilla.org/en-US/doc … ement/text
For rotate text in svg you need to use a transformation https://developer.mozilla.org/en-US/doc … /transform
With Qt you can see https://doc.qt.io/qt-6/qtransform.html

Hallo plc-user,
Wow that's very good, thank you for the great support.

Best regards
Laurent

About closed polygon, see const QDomElement PartPolygon::toXml(QDomDocument &xml_document) const

if (!m_closed) xml_element.setAttribute("closed", "false");

So if the the polygon is not close, the attribute is not present.

In svg there is not close or open polygon.
There is polygon (close) and polyline (open)

Hallo plc-user,
ich bin auch schon einige male auf  dieses Verhalten bei dynamischen Text gestoßen.
Ich nehme an Du hast den Text  in den Editor gezogen, beschriftet und dann die Ausrichtung angepasst. Wenn Du den Text in den Editor ziehst (Unterstrich löschen), Textausrichtung anpasst und dann den Text schreibst, dann erhältst du das erwartetete Ergebnis wie auch bei der SVG.
Trotzdem ist Textausrichtung in QET nicht ganz optimal. Hauptgrund ist sicher das QGraphicsTextItem, die Basisklasse für den dynamischen Text, nur die Textausrichtung "oben Links" kennt. Ich denke in QET wird die Textlänge berechnet und damit dann der Einfügepunkt des Textes entsprechend verschoben. Das verschieben des Einfügepunktes kann man auch gut an den x/y Koordinaten nachvollziehen.
Besser wäre sicherlich wenn der Punkt der Ausrichtung auch der Einfügepunkt ist, wie bei anderen CAD-Systemen auch.
Ich hoffe es hilft.
Gruß
Achim

With translator:
Hello plc-user,
I have also encountered this behaviour with dynamic text several times.
I assume you have dragged the text into the editor, labelled it and then adjusted the alignment. If you drag the text into the editor (delete the underline), adjust the text alignment and then write the text, you will get the expected result as with SVG.
Nevertheless, text alignment in QET is not quite optimal. The main reason is certainly that QGraphicsTextItem, the base class for dynamic text, only recognises the text alignment "top left". I think the text length is calculated in QET and the insertion point of the text is then moved accordingly. The shifting of the insertion point can also be easily understood by the x/y coordinates.
It would certainly be better if the point of alignment was also the insertion point, as with other CAD systems.

Greetings
Achim

Hello everybody!

I decided to cancel the project "QET_Element2SVG"! 

Instead I added SVG-Output-Support to QET_ElementScaler!

In this context the order of commandline-parameters for QET_ElementScaler had to be adjusted!
So please:
Read the Readme and the scripts and batches provided on the github-page:
https://github.com/plc-user/QET_ElementScaler

In the Release-Section there are binaries for Debian GNU Linux (unstable), ReactOS (32bit) and Win10 (64bit) available, but you should be able to compile the sources on other platforms.

The software is re-written in great parts and may contain errors!

So:
Test the software and report errors, inconsistencies, or simply praise!

Best regards
  plc-user

Thank you, I can't wait to try this work but at the moment I have to fight for my health against death....

Regards,
Laurent

Hello plc-user,

On these url's find you about markers in SVG

https://www.svgbasics.com/markers.html
https://www.w3.org/TR/SVG11/painting.html#MarkerElement

with kind regards,
Erik

Hello plc-user,

dis_mag_term_3f-1.elmt.svg
Missing line left under

With kind regards,
Erik

Hello Erik, (and all others!)

on https://github.com/plc-user/QET_ElementScaler you'll find a new version of QET_ElementScaler in which the handling of line-width and line-style for SVG-output is re-worked.

Here you see an example in the picture (top: SVG, bottom: Element-Editor) and in Element- and SVG-file.
Additionally your example with the re-worked styles is also attached.

I guess I found a quite usable solution...

Please test the new version with your "favorite" elements!
Thanks in advance! 

Best regards
  plc-user