Created attachment 89634 [details] Wrong arrowheads. Look at the attached screenshot - on the right is 4.1, on the left master. Notice the 6th, 7th, 10th and 11th arrowhead, it is broken [not even in the listbox, but when painted, it is wrong the same way]. Also the 5th does not look entirely correct, but that was there already in 4.1 it seems.
CONFIRMED in LO 4.2.0.0.beta1 on Ubuntu 12.04.3 REPRO: - Open LibreOffice Draw - Click on 'Arrowheads' drop-down icon in toolbar - See the incorrect/distorted arrowheads - (Optionally), draw out example lines using these tools This distortion does not appear in the arrowheads in the drop-down in LO 4.1.2.3 or LO 3.5.7.2. (I'm not sure I can confirm Jan's comment re: the 5th icon -- it looks pretty similar in all versions tested)
Created attachment 89701 [details] 4.2.0.0.beta1 drawing document exhibiting unexpected arrowheads Attaching document created in LO 4.2.0.0.beta1. This document appears the same in 3.5.7.2 and 4.1.2.3; the (unexpected) arrowheads must be baked-in to the ODG document.
Not only arrow heads are broken, but other combined shapes are broken too. In LO 4.1 do this: Draw a rectangle and then a circle on top of it. Combine them, so that you get a rectangle with a hole. Save it. Open it in LO 4.2. Notice the circle has a wrong position.
Created attachment 89843 [details] Arraw heads with zM instead of zm The problem is not in LO42 but in LO41. LO41 writes the sequence zm even in cases the arrow head has in its definition zM (which would avoid the problem). Therefore a fix would be needed in LO41. AOO401 has the same problem. I have attached a new set of arrow heads, which use zM, but because of this saving behavior of LO4.1 (save mode "ODF 1.2 extended (recommened)"), it does not solve the problem. Nevertheless this file should be used, because the path is then unambiguous, independent of whether the 'current point' is interpreted wrong or correct. Currently those drawings, which use the "combine" feature, can only be shown correctly, when you set LO41 to save in "ODF 1.2 extended (compat)" mode. Then the drawings are shown correctly in LO41, LO42, AOO401, and AOO41. When you then save such drawing in LO42 or AOO41, the drawings will remain correct, even when opening in LO41. Add in the release note, that for a smooth change from LO41 to LO42, LO41 should be used in "compat" mode?
(In reply to comment #4) > Created attachment 89843 [details] > Arraw heads with zM instead of zm (I didn't know what a .soe file was: https://help.libreoffice.org/Impress/Loading_Line_and_Arrow_Styles) Should that file have mimetype application/octet-stream? (perhaps more gremlins in the Bugzilla attachment processing code) > The problem is not in LO42 but in LO41. Do you mean that the problem is not *introduced* in 4.2, but in 4.1? (and if so, when?) > LO41 writes the sequence zm even in > cases the arrow head has in its definition zM (which would avoid the > problem). Therefore a fix would be needed in LO41. What does 4.2 write? > I have attached a new set of arrow heads, which use zM, but because > of this saving behavior of LO4.1 (save mode "ODF 1.2 extended > (recommened)"), it does not solve the problem. ok > Currently those drawings, which use the "combine" feature, can only be shown > correctly, when you set LO41 to save in "ODF 1.2 extended (compat)" mode. > Then the drawings are shown correctly in LO41, LO42, AOO401, and AOO41. Are you suggesting that we should change the saving behavior of 4.1/4.2? > Add in the release note, that for a smooth change from LO41 to LO42, LO41 > should be used in "compat" mode? What about 4.2? Are you suggesting that you do not see this behavior in 4.2?
This becomes a little bit long and perhaps discussion should be moved to mailing lists dev and ux. (In reply to comment #5) > (In reply to comment #4) > > Created attachment 89843 [details] > > Arraw heads with zM instead of zm > > (I didn't know what a .soe file was: > https://help.libreoffice.org/Impress/Loading_Line_and_Arrow_Styles) > > Should that file have mimetype application/octet-stream? (perhaps more > gremlins in the Bugzilla attachment processing code) I think, MIME type is "text/xml". > > > The problem is not in LO42 but in LO41. > > Do you mean that the problem is not *introduced* in 4.2, but in 4.1? (and > if so, when?) > > > LO41 writes the sequence zm even in > > cases the arrow head has in its definition zM (which would avoid the > > problem). Therefore a fix would be needed in LO41. > Oh, there I was wrong. I've looked a little bit deeper now. LO 4.1 writes the path as specified in ODF1.2, and LO4.2 interprets it as if the file comes from an older version, which had interpreted the path wrong. That has been introduced with commit id=223f6b631c1b087754c0f9051fb55f029f2503ce. So that is introduced in 4.2. The problem in LO4.1 is, that LO4.1 does not preserve absolute commands in a path, but converts them to relative commands when re-save the file. Therefore it will not help, to deliver the next version of the LO4.1 series with arrow heads, which use absolute commands. Such has been my first thought of a fix. > What does 4.2 write? LO 4.2 writes zM in all cases, same as AOO4.1 does. That was done by the commit mentioned above. Those files are read correctly in older versions. > > > I have attached a new set of arrow heads, which use zM, but because > > of this saving behavior of LO4.1 (save mode "ODF 1.2 extended > > (recommened)"), it does not solve the problem. > > ok > > > Currently those drawings, which use the "combine" feature, can only be shown > > correctly, when you set LO41 to save in "ODF 1.2 extended (compat)" mode. > > Then the drawings are shown correctly in LO41, LO42, AOO401, and AOO41. > > Are you suggesting that we should change the saving behavior of 4.1/4.2? That is a very difficult question. I had a long private discussion with Armin Le Grand, how to solve these problems. There is no reliable way to detect, whether a file was written with the correct ODF1.2 interpretation of the path or not. For AOO only wrong interpretations exists, because it had not followed the way of LO. But for LO we have the situation, that already some versions write the correct interpretation and therefore such files exist. Unfortunately they write relative commands and therefore produce this ambiguity. Changing the saving behavior of 4.1 is one option. Another option is to let the user decide how to open the file, a kind of "He user, I've noticed a zm command. How should I interpret it?". The crucial point in the discussion with Armin was, whether an explicit decision about the interpretation is expecting too much of average users. > > > Add in the release note, that for a smooth change from LO41 to LO42, LO41 > > should be used in "compat" mode? > > What about 4.2? Are you suggesting that you do not see this behavior in 4.2? The files written by LO4.2 do not have the problematic command sequence zm and therefore can be read correctly in all versions.
Regina Henschel committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4d42cf31ce8ce7962737106b66cf94adb098c6bd Related fdo#71919: Correct arrow heads for new installations. 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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Regina: I took your new .soe definition and pushed it with your name - I hope it is OK? :-) - thank you so much for the fix! It still remains to be sorted out what to do with the older files though; ideally we should have a different bug for that, then again, there is quite some context here already...
Yes you can take the file. But the problem for LO4.1 is, that is does not write the arrow heads as defined in the file, but changes the path definitions.
(In reply to comment #6) > Changing the saving behavior of 4.1 is one option. Another option is to let > the user decide how to open the file, a kind of "He user, I've noticed a zm > command. How should I interpret it?". The crucial point in the discussion > with Armin was, whether an explicit decision about the interpretation is > expecting too much of average users. Sometimes we can't even prompt the user -- e.g. if we're doing headless document conversion on the command line (although in those cases I guess we could print some kind of warning about the situation)
Regina Henschel committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=305d5021f1d968d01a031ad2e7e540fb44eb75c6&h=libreoffice-4-2 Related fdo#71919: Correct arrow heads for new installations. It will be available in LibreOffice 4.2. 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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Setting to Fixed as of comment 11 and assigning Regina.
Verified with Version: 4.2.0.2 Build ID: 601a398b803303d1a40a3299729531824fe0db56 - set Closed - Sophie
*** Bug 65516 has been marked as a duplicate of this bug. ***