Bug 83360 - wrong behaviour for svg:viewBox and svg:d in draw:connector
Summary: wrong behaviour for svg:viewBox and svg:d in draw:connector
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
(earliest affected) release
Hardware: Other Linux (All)
: high normal
Assignee: Not Assigned
Whiteboard: target:5.3.0
Depends on:
Reported: 2014-09-01 16:08 UTC by t_d_l_c
Modified: 2016-09-29 15:12 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:

example files (14.65 KB, application/gzip)
2014-09-01 16:08 UTC, t_d_l_c
Screenshots for the example files (740.32 KB, application/x-gzip)
2016-04-29 09:19 UTC, t_d_l_c

Note You need to log in before you can comment on or make changes to this bug.
Description t_d_l_c 2014-09-01 16:08:12 UTC
Created attachment 105568 [details]
example files

Draw seems to be incompatible with some values of svg:viewBox and svg:d in the draw:connector element. It seems to assume that all values are thousandths of a centimetre. All other values don't work.

I'm working on a converter that creates odg files. While doing that, I've come across the problem, that calligra flow and libre office don't display all files equally, even though they both create odg files.
One problem is that when you create a file in calligra flow with a connector that is only connected on one end or not connected at all. These files are not displayed correctly when opened in libre office draw. I've attached a file created with calligra flow with a connector that is not connected on one of its ends (calligra_created.odg). In libre office connections like this always end near the top left corner.

I've unpacked a libre office draw file and noticed that is uses thousandths of a centimetre in svg:viewBox and svg:d of draw:connector. Draw seems to rely on that. This can be seen when you devide all values by 10. I deleted the last digit for all numbers. Of course this is not an exact divions but it should be almost the same curve as the values are very big. Then libre office draw diplays the open end of the connection near the top left corner. In calligra flow both files look the same.

Created by draw (draw_created_original.odg):
<draw:connector draw:style-name="gr2" draw:text-style-name="P1" draw:layer="layout" svg:x1="9.8cm" svg:y1="11.4cm" svg:x2="5.829cm" svg:y2="20.362cm" draw:start-shape="id1" svg:d="M9800 11400v4732h-3971v4230" svg:viewBox="0 0 3972 8963">
After removing one digit (draw_created_modified.odg):
<draw:connector draw:style-name="gr2" draw:text-style-name="P1" draw:layer="layout" svg:x1="9.8cm" svg:y1="11.4cm" svg:x2="5.829cm" svg:y2="20.362cm" draw:start-shape="id1" svg:d="M980 1140v473h-397v423" svg:viewBox="0 0 397 896">

This is a big problem for my converter that creates a lot of half-connected connectors and also causes compatibility issues between calligra flow and draw. Help would be very appreciated.
Comment 1 Buovjaga 2014-11-14 08:44:30 UTC
(In reply to t_d_l_c from comment #0)
> I've attached a
> file created with calligra flow with a connector that is not connected on
> one of its ends (calligra_created.odg). In libre office connections like
> this always end near the top left corner.


Win 7 64-bit Version:
Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827
TinderBox: Win-x86@39, Branch:master, Time: 2014-11-12_01:10:08
Comment 2 Armin Le Grand 2016-03-24 16:30:04 UTC
Conversion of svg:x2 and svg:y2 in Converter::convertMeasure is correct during import from SdXMLConnectorShapeContext::processAttribute, but the svg:d seems to make trouble - if removing it, it looks good.
Not sure how the file *should* look like. A screenshot would have been nice. This way, just to see how it should look like, I have to install Calligra...
Comment 3 Armin Le Grand 2016-03-29 08:29:31 UTC
Managed to create a sample in calligra which behaves as described. On 1st look it just seems as if the end pos is correct, but the path added is not. When leaving out the path all is good. A simple test for the path being valid would e.g. be to check last point/end point and first point/start point for being equal. It is not equal in the examples, thus may be simply an error in calligra to write a path at all with wrong content
Comment 4 Armin Le Grand 2016-03-29 10:43:35 UTC
Checked with what Office does, for Connectors StartPosition and EndPosition are always written, these are equal with the connector path's start and end points, independent of the start/end points being connected to objects.
For the Caligra part only non-connected points get written, and a path who's start and end points seem to have nothing in common with the connector's start/end points - why ever this is done.
Thus it would be good to check for these points and Calligra as producer, checking if this is possible...
Comment 5 Armin Le Grand 2016-03-29 13:29:21 UTC
Checked that indeed Office always writes the connector Start/End redundant in the paths data as 1st/last points, independent from connector being connected on one end or not. Writing the path of the connector is used as 'buffering' the connector layout calculations and to make reading ODF easier for other formats. Based on that it makes sense to flush this buffered data when inconsistencies between the start/end point coordinates and the path data exists. Trying that...
Comment 6 t_d_l_c 2016-04-29 09:19:34 UTC
Created attachment 124715 [details]
Screenshots for the example files

I add some screeshots for the example files. Using Libre Office Version: Build-ID: 368 . This might be our own build (city of munich). 

Calligra Flow Version:
Version 2.7.1 in KDE 4.12.0
Comment 7 Commit Notification 2016-07-07 20:35:29 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "master":


tdf#83360 avoid inconsistent connector path data

It will be available in 5.3.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:

Affected users are encouraged to test the fix and report feedback.
Comment 8 Armin Le Grand 2016-08-12 16:00:55 UTC
Re-checked if the import could correc t a connector from the example files that is connected on one end and free on the other by taking the included svg:d and scaling it to start/end point. This is not possible, since the connected end has no coordinates at connector input yet- the connectors are connected at end of page loading using a helper class. This means that not all data needed to scale-correct the svg:d is given at that point - the connected point is missing.
Setting the connection resets the user-defined path and the polygon - for good reason. The defining values are the connector, the svg:d is redundant, convenience information.
So this can (and should not) be done - if connector functionality is wanted, the connector has to be resetted it's svg:d and be re-layoutable from that moment on. Of course it would look better/closer to the source when the correct type of connector would be used which is not the case.
Comment 9 Armin Le Grand 2016-09-29 15:12:45 UTC
Works as intended, no better tings to do here