Launchpad has imported 33 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=47406.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2012-03-16T12:02:26+00:00 SK wrote: Created attachment 58549 File created in 3.4.3 with series of examples of the problem. All graphics that have internal circuits (non-circular) are getting severely messed up. Any file generated in pre 3.5 does not render graphics correctly. Even worse if you subsequently save the file in 3.5 file is damaged such that graphic problem will now appear if you open in 3.4. This is totally a show stopper we have band 3.5 from our company until this problem is resolved. I will attach file. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/0 ------------------------------------------------------------------------ On 2012-03-16T12:04:16+00:00 SK wrote: Created attachment 58550 File created in 3.4.3, opened in 3.5.1 then saved. Note when opening file in all versions of LO graphics are now screwed up after 3.5.1 has saved. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/1 ------------------------------------------------------------------------ On 2012-03-16T19:34:18+00:00 S-joyemusequna wrote: Confirmed with LibO 3.5.1 on Windows XP. This is a regression. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/2 ------------------------------------------------------------------------ On 2012-03-20T15:47:36+00:00 Pmladek-y wrote: I add some draw developers into CC. Please, look at it ASAP. It would be great to fix this for 3.5.2-rc2. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/3 ------------------------------------------------------------------------ On 2012-03-20T16:48:36+00:00 Rb-henschel wrote: It happens too when you copy a combined shape from Draw to Writer. Dev build Build ID: e40af8c-10029e3-615e522-88673a2-727f724 (3.5.0 beta3) has been OK. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/4 ------------------------------------------------------------------------ On 2012-03-20T17:47:44+00:00 Rb-henschel wrote: Build Build-ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735 (3.5.0rc3) is already faulty. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/5 ------------------------------------------------------------------------ On 2012-03-20T18:00:57+00:00 Lo-bugs wrote: Created attachment 58773 gdb session with backtrace from the warning I am just throwing this onto the pile. If it is a distraction, please let me know. Observations on build from master commit cc32ce4, pulled 2012-03-09, and configured with --disable-mozilla --enable-symbols --enable-dbgutil --enable-crashdump --disable-build-mozilla --without-system-postgresql --enable-python=internal running on ubuntu-natty 32-bit with desktop "gnome (no effects)". I named the sample document on the command line. When LibreOffice displayed the document, I clicked with mouse in the coloured area of the first column of the first row after the headings. The program displayed 15 times the message ... warn:sfx2.appl:13216:1:/home/terry/lo_hacking/git/libo/sfx2/source/appl/module.cxx:396: SfxModule::GetFieldUnit: no metric item in the module implemented by '8SwModule'! I am attaching typescript of gdb session. Backtrace full from the first occurrence of the warning starts around line 94, plain backtrace starts around line 387. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/6 ------------------------------------------------------------------------ On 2012-03-21T09:31:13+00:00 Sumuthu wrote: More info: Pasting the object from Draw to Writer (or Writer to Draw), mirrors the boxes (vertically and up) (even more) - I guess some issue with either positioning or the box positioning. If you keep doing (the copy-paste b/w draw and writer) the box in the first image keeps moving up. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/7 ------------------------------------------------------------------------ On 2012-03-21T09:33:34+00:00 Sumuthu wrote: CC'ing writer developers as well. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/8 ------------------------------------------------------------------------ On 2012-03-23T08:55:14+00:00 Rb-henschel wrote: Some new unfilled array heads are affected too, for example the unfilled triangle and the unfilled diamond. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/9 ------------------------------------------------------------------------ On 2012-03-23T14:32:58+00:00 Rb-henschel wrote: If you combine a rectangle with a triangle inside in Draw, it looks fine at a first glance. But if you reload the file, the position of the inner triangle is wrong. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/10 ------------------------------------------------------------------------ On 2012-03-23T15:19:44+00:00 Rb-henschel wrote: Created attachment 58932 Source for the svg file. Document generated with Apache OpenOffice. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/11 ------------------------------------------------------------------------ On 2012-03-23T15:21:25+00:00 Rb-henschel wrote: Created attachment 58933 result of export to svg Result of export to svg by Apache OpenOffice. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/12 ------------------------------------------------------------------------ On 2012-03-23T15:54:23+00:00 Tbehrens-u wrote: Created attachment 58940 Tweaked svg from before The svg export use absolute coordinates in the svg:d statement, and is thus immune to the bug - I've pasted the exact same svg:d statement from the bugdoc's content.xml into it, and adjusted the viewport - now, firefox displays it exactly as LibreOffice. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/13 ------------------------------------------------------------------------ On 2012-03-23T16:51:29+00:00 Tbehrens-u wrote: Created attachment 58943 Fix for the export problem Fix for the export problem (that was still using the old, incorrect way to keep track of the current point) - Fridrich, Regina, any chance you could test-drive that? Now LibO export should read fine on import again. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/14 ------------------------------------------------------------------------ On 2012-03-26T10:23:07+00:00 Libreoffice-bugs wrote: Thorsten Behrens committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=a2ee8055e9c136923f0244fe289cac6377933c31 Fix fdo#47406 incorrect relative moves after closePath Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/15 ------------------------------------------------------------------------ On 2012-03-26T10:58:57+00:00 Libreoffice-bugs wrote: Fridrich Štrba committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7a19798c73fd39d8d69ff6364f0696e68cdd1381 Compatibility option for incorrect relative moves after closePath (fdo#47406) Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/16 ------------------------------------------------------------------------ On 2012-03-26T11:06:34+00:00 Libreoffice-bugs wrote: Thorsten Behrens committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=db3597cef07a0f659be5617d9148069c7fb4a5a8&g=libreoffice-3-5 Fix fdo#47406 incorrect relative moves after closePath It will be available in LibreOffice 3.5.3. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/17 ------------------------------------------------------------------------ On 2012-03-26T11:12:44+00:00 Libreoffice-bugs wrote: Fridrich Å trba committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b8fb2df5491937ccc7eb422544e25f18a6bc787c&g=libreoffice-3-5 Compatibility option for incorrect relative moves after closePath (fdo#47406) It will be available in LibreOffice 3.5.3. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/18 ------------------------------------------------------------------------ On 2012-03-26T14:51:31+00:00 Libreoffice-bugs wrote: Thorsten Behrens committed a patch related to this issue. It has been pushed to "libreoffice-3-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=60a291d006890bc539d5cd19d03a930628d7d756&g=libreoffice-3-5-2 Fix fdo#47406 incorrect relative moves after closePath It will be available already in LibreOffice 3.5.2. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/19 ------------------------------------------------------------------------ On 2012-03-26T14:52:01+00:00 Libreoffice-bugs wrote: Fridrich Å trba committed a patch related to this issue. It has been pushed to "libreoffice-3-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=befb1c7e26b79ae97d802659f3386882d4044251&g=libreoffice-3-5-2 Compatibility option for incorrect relative moves after closePath (fdo#47406) It will be available already in LibreOffice 3.5.2. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/20 ------------------------------------------------------------------------ On 2012-03-29T09:58:57+00:00 Michael Meeks wrote: With all the patches merged to libreoffice-3-5-2 - should this be closed ? Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/21 ------------------------------------------------------------------------ On 2012-03-29T23:16:32+00:00 Rb-henschel wrote: *** Bug 47590 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/22 ------------------------------------------------------------------------ On 2012-04-03T13:58:47+00:00 Fridrich wrote: Verified in 3.5.2rc2 Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/23 ------------------------------------------------------------------------ On 2012-04-12T12:06:50+00:00 Tbehrens-u wrote: *** Bug 48443 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/37 ------------------------------------------------------------------------ On 2012-04-12T18:38:34+00:00 Ferry Toth wrote: In 3.5.2 the document is opened correctly. However when saved and opened in either LO3.4.4 or OO3.2.1 the document still appears to be broken. I guess is partially solved. This part is relevant for users migrating to the latest version. The second and equally important part is not yet solved. This is relevant for users migrating in a phased manner (some users migrate earlier then others) or exchanging Open Document with other organizations. For the latter users choosing Open Document may for a large part be based on the supposed interoperability between different OS, Office application vendors and Office versions. For this reason I would like to reopen this bug. Sorry. Ferry Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/39 ------------------------------------------------------------------------ On 2012-04-12T19:06:53+00:00 Barta-c wrote: LibO 3.3.x and 3.4.x life cycle is terminated so there's no chance the bug can be backported to work with those older releases Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/40 ------------------------------------------------------------------------ On 2012-04-12T20:14:36+00:00 Libreoffice-z wrote: @Ferry Toth: <https://wiki.documentfoundation.org/BugReport_Details#How_to_reopen_Bugs>! I do not understand what you expect. As tommy27 explains the fix is in all future releases, what else can be done? Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/41 ------------------------------------------------------------------------ On 2012-04-12T21:46:19+00:00 Ferry Toth wrote: What I expect is that documents created in the ODF format can be worked on by future versions of LO and that documents created by future versions of LO can be worked on by previous (even obsolete) version of LO, at least as long as saved in an ODF version supported by the older reader. This has always been one of the big problems with Microsoft's products, and one of the main attractions of OpenOffice, LibreOffice etc. In comment #22 is said all the patches are merged into 3.5.2 and so the bug should be closed. But as is easily verified (as I have done), the 2nd problem in the original bug is not solved: "Even worse if you subsequently save the file in 3.5 file is damaged such that graphic problem will now appear if you open in 3.4. This is totally a show stopper we have band 3.5 from our company until this problem is resolved. I will attach file." I think a bug can be closed when it's fixed. And I hear it can only be fixed in future versions, for me 3.5.3 would be nice. But it is definitely not fixed in 3.5.2. So unless I misread somebodies comments, I think I reopened this rightfully. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/42 ------------------------------------------------------------------------ On 2012-04-12T22:42:14+00:00 Tbehrens-u wrote: (In reply to comment #28) > I think a bug can be closed when it's fixed. And I hear it can only be fixed > in > future versions, for me 3.5.3 would be nice. But it is definitely not fixed in > 3.5.2. > Hi Ferry - so, how do you suggest we should fix it? Since all versions before 3.5.0 interpret svg:d paths incorrectly? Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/43 ------------------------------------------------------------------------ On 2012-04-13T14:34:53+00:00 Ferry Toth wrote: You could, if a file is created in a version previous to 3.5, on save save it back in the same old incorrect format. Or you could offer a setting in 3.5 'save in pre-3.5 compatible format'. (I admit these solutions have a percentage of M$). I have now idea what you mean exactly by 'interpret svg:d paths incorrectly' of course. I only know that 3.5 has a different way to interpret the odf, odg or whatever document then previous versions, and that is causing the problem. Using the same (wrong way) solves the problem - for now. Ferry Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/44 ------------------------------------------------------------------------ On 2012-04-15T17:11:16+00:00 Jumbo4444 wrote: Hello, Could a 3.4.7 be planed to be able to "interpret svg:d paths" correctly? Otherwise, we force people to jump to 3.5 version, when it is not completely stable. This problem seems to create a gap between 3.5 and all previous version, which have big consequences on Gallery themes https://bugs.freedesktop.org/show_bug.cgi?id=48483 Gallery built with previous 3.5 are not correctly interpreted by LibO 3.5 Gallery built with LibO 3.5 are not correctly interpreted by previous 3.5 Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/45 ------------------------------------------------------------------------ On 2012-05-02T10:24:03+00:00 Christopher M. Penalver wrote: Ferry Toth, regarding https://bugs.freedesktop.org/show_bug.cgi?id=47406#c25 , LO<3.4 has reached End of Life as per http://wiki.documentfoundation.org/ReleasePlan . If your infrastructure chooses to use ancient (OOo 3.2.1) and EoL (LO 3.4.4) versions of software, that's not a problem in LO upstream, that is an infrastructure/downstream problem. Regarding https://bugs.freedesktop.org/show_bug.cgi?id=47406#c28 , upstream LO is not tasked to workaround broke code in EoL releases. Regarding https://bugs.freedesktop.org/show_bug.cgi?id=47406#c30 : >"You could, if a file is created in a version previous to 3.5, on save save it back in the same old incorrect format." This suggestion is simply ridiculous. Since you are using Ubuntu, you are welcome to chase a fix up with the Ubuntu project as they do provide backport support for the 3.4.x branch in Oneiric. LO -> RESOLVED WONTFIX Laurent BP, any discussion about Release Plan changes should be done on the appropriate mailing list, not here. Reply at: https://bugs.launchpad.net/df- libreoffice/+bug/979320/comments/46 ** Changed in: df-libreoffice Status: Unknown => Won't Fix ** Changed in: df-libreoffice Importance: Unknown => High ** Bug watch added: freedesktop.org Bugzilla #48483 https://bugs.freedesktop.org/show_bug.cgi?id=48483 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to libreoffice in Ubuntu. https://bugs.launchpad.net/bugs/979320 Title: Particular Subtracted shapes not compatible LibO 3.4 - 3.5 Status in LibreOffice Productivity Suite: Won't Fix Status in “libreoffice” package in Ubuntu: Incomplete Bug description: Certain shapes drawn in earlier LO versions (<3.4.4) are greatly distorted in LO 3.5.2 (on windows) and LO 3.5.1.2 (Precise). Vice versa when saved in 3.5.1 correctly the documents are broken in 3.4.4 (Oneric). In our case our company logo embedded in writer documents is one of the problems. For us this means virtually all old documents are messed up when opened with LO 3.5.2 while newly created document are broken when viewed with LO 3.4.4. I don't know if many users are affected by this, but for us it certainly is a stopper to migrate to LO 3.5.1 or 3.5.2 and as a result to Precies. Ferry To manage notifications about this bug go to: https://bugs.launchpad.net/df-libreoffice/+bug/979320/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
