Created attachment 148881 [details]
Container with test files in odg and odp format

In the attached files you should see in all cases two equal sized circles side-by-side. Open the files in PowerPoint, Calligra Karbon or Scribus e.g. to see, how they should render.

The error is caused by the patch from https://bz.apache.org/ooo/show_bug.cgi?id=119974, which was integrated in LibreOffice by https://cgit.freedesktop.org/libreoffice/core/commit/?id=fbc42f30bc0fbca4d12f34059f2b2b821921d849.

The bugreport in bz.apache.org has in comment#3 the following reasoning for that patch:

<quote>

There are two issues about this defect.
<1>Ellipse shape becomes bigger
Root Cause:
this sample is created by odf version 1.1 app.
the enhanced path for ellipse is the command "U" or "Z", the parameter is (x y w h t0 t1), it means that draws a segment of an ellipse. The ellipse is specified by the center(x, y), the size(w, h) and the start-angle t0 in degrees and end-angle t1 in degrees.
But in this odf(version 1.1) , w,h mean the diameter, in AOO3.4, it means the radius, so the ellipse created by odf version 1.1 app will becomes 2 times in Symphony Vienna.
2. Resolution:
In this case, the shape never use the default view box which is (0 0 21600 21600), but use (0 0 10000 10000). so if it is not the default view box, when draw a segment of ellipse, set the w & h in the enhanced path to half.
While there is a special senaria that odf version 1.1 app open a ms file,and saved it to odf file, because the ms filter use the preset shape design which viewbox is (0 0 21600 21600), so when export to odf file, it use the default viewbox, but the w, h in the U command parameters still means the diameter, so should check if the shape is from ms shape, that is the value of draw:type is started with "mso", and has the default viewbox, then set the w & h to half.

<2>Ellipse shape display too large in MS office after save odp file to ppt format file 
Root Cause:
The custom shape ellipse viewbox width and height value in odf version 1.1 are 10000, in odf version 1.2 are 21600. For example, when AOO3.4 importing a default ellipse object created by odf version 1.1 app, the ellipse default viewbox value will be ingored and using 10000 as the the viewbox value to compute. But the viewbox value in object model is not changed. So if saving the ellipse to ppt or odp by AOO3.4, the viewbox value will be 10000, but other values are based on 21600. 
Resolution:
If the ellipse is a default path object, but the viewbox value is not default one, set default viewbox value to the ellipse object model when importing by AOO3.4.

</quote>

The statement in part <2> of the comment about the viewBox values in ODF is wrong. ODF has no such rule or any default values for viewBox. The problem of using 10000 in ODF 1.1 format and using 21600 in ODF 1.2 format is a special problem of Symphony. OpenOffice.org has always used 21600 for its own custom shapes. Besides that, I think it is wrong design to adapt it inside that part, which does the general generating of polypolygons for rendering, instead of adapting it on import. 

The comment in part <1> is correct. That is https://issues.oasis-open.org/browse/OFFICE-3711. But all applications I aware of, use the values w and h as radius. This too seems to be a special problem of Symphony. OOo 3.2.1 has already used w and h as radius, and OOo 2.4.3 at least for non-default custom shapes.

A special handling of shapes generated by Symphony is no longer needed, because Symphony was discontinued 2012. In case a user really needs to handle old Symphony files, the user can use AOO3.4 to convert them. So as a first step to make handling of command U conform to ODF, I'm going to remove at least changing the viewBox values.

In case you are aware of special situation I need to consider, please leave a comment here.