https://bugs.documentfoundation.org/show_bug.cgi?id=123157
Bug ID: 123157
Summary: Special Symphony shape handling in custom shape
command U prevents ODF conform rendering
Product: LibreOffice
Version: Inherited From OOo
Hardware: x86-64 (AMD64)
OS: Windows (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Draw
Assignee: libreoffice-bugs@lists.freedesktop.org
Reporter: rb.hensc...@t-online.de
Blocks: 121845
Created attachment 148881
--> https://bugs.documentfoundation.org/attachment.cgi?id=148881&action=edit
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.
Referenced Bugs:
https://bugs.documentfoundation.org/show_bug.cgi?id=121845
[Bug 121845] custom shape with command U (angleellipse) is wrongly drawn
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
