Problem with displaying elements

This element are a wrong hostspot, just open in editor and save again.

Maybe send element here?

You are perfectly right, Laurent!

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

Hotspot miscalculated the rounding of the arc, a workaroud is to add 2 invisible little line on the two arc center...for the moment.

Yes, I think it does not calculate the extreme position of the ARC primitive, is the case if we stretch the arc into an ellipse :
https://github.com/qelectrotech/qelectr … e.cpp#L405
https://github.com/qelectrotech/qelectr … t.cpp#L249

Ctrl + A for selected all parts, is wrong!

Maybe here?

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?

Yes, I think you are right, Laurent!
In the function starting here:
https://github.com/qelectrotech/qelectr … y.cpp#L189
The ELSE branches ensure that only the start and end points of the ARC are used for the calculation of the surrounding RECT size. In this case, this is counterproductive!

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...

For QET_ElementScaler I now use this (mathematically correct) determination for the min-max values of an elliptical arc:

    // 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