// calculate points on ellipse-circumference:
    // x = a ⋅ cos(t)
    // y = b ⋅ sin(t)
    // with t = 0 .. 2*pi = ([0 .. 360]/360)*2*pi
    // for ARC with x- and y-offset in a loop from Start to (Start+Angle):
    for (int i = Start; i <= (Start + Angle); i++){
        double val_x = X + (Width/2) * (1 + cos((i%360)/360.0*2*pi));
        double val_y = Y + (Height/2) * (1 - sin((i%360)/360.0*2*pi));
        XYMinMax.add(val_x, val_y);
    }

This may be too time-consuming for the productive version of QET, but here I allowed that "luxury-version"...   
Now available here: https://github.com/plc-user/QET_ElementScaler

Is there anything against always assuming an "ellipse" for the determination of the surrounding rectangle?
(But please don't expect me to adopt this today: Before I have managed to get familiar with QT-programming and the IDE it will be Christmas again... )

Another thought for ARCs:

For the determination of the surrounding rectangle, it might be easier to limit the number of case distinctions. For this it might be helpful if (at the latest when saving the XML file) we always keep the angles of the ARC in the positive range?
These arcs are identical:

Start = -10 / Angle =  30
Start =  20 / Angle = -30
Start = 350 / Angle =  30

For case distinctions in internal calculations, however, it might help...

Implemented normalisation for start and angle of ARCs in QET_ElementScaler and just released a new version on github.
Maybe it helps...

https://github.com/qelectrotech/qelectr … c.cpp#L165

/**
 * @brief PartArc::sceneGeometricRect
 * @return the minimum,
 * margin-less rectangle this part can fit into in scene coordinates.
 * It is different from boundingRect() because it is not supposed
 * to imply any margin,
 * and it is different from shape because it is a regular
 * rectangle, not a complex shape.
 */
QRectF PartArc::sceneGeometricRect() const
{
    return mapToScene(QetGraphicsHandlerUtility::rectForArc(m_rect, m_start_angle/16, m_span_angle/16)).boundingRect();
}

... or at least in that file?

Ctrl + A for selected all parts, is wrong!

    // calculation taken from QET-sources:
    int upwidth = ((width/10)*10)+10;
    if ((width%10) > 6) upwidth+=10;

    int upheight = ((height/10)*10)+10;
    if ((height%10) > 6) upheight+=10;

Just a thought, Laurent:
Can it be that ARCs aren't taken into account for calculating Element's size?
The other graphical elements seem to be used for calculating size...

You are right, too, Vbxler!

The definition-line of your Start-Element has these values:

hotspot_y="14" height="40" width="90" hotspot_x="45"

and shows the graphical errors.
The corrected version of the file from QET_ElementScaler has these values:

hotspot_y="15" height="40" width="110" hotspot_x="55"

and shows perfect graphics.

When I re-open the corrected file in Element-Editor and save it again, the false values are written to file again.
It seems that the calculation of hotspots and size of the element is broken in Element-Editor at the moment...

You are perfectly right, Laurent!

Corrected the files from packed file with QET_ElementScaler and added here as *.tar.gz

20_logic/2020_flow_chart/202010_flow_chart/20201000_start.elmt
20_logic/2020_flow_chart/202010_flow_chart/20201001_end.elmt