Created attachment 58549 [details] 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.
Created attachment 58550 [details] 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.
Confirmed with LibO 3.5.1 on Windows XP. This is a regression.
I add some draw developers into CC. Please, look at it ASAP. It would be great to fix this for 3.5.2-rc2.
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.
Build Build-ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735 (3.5.0rc3) is already faulty.
Created attachment 58773 [details] 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.
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.
CC'ing writer developers as well.
Some new unfilled array heads are affected too, for example the unfilled triangle and the unfilled diamond.
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.
Created attachment 58932 [details] Source for the svg file. Document generated with Apache OpenOffice.
Created attachment 58933 [details] result of export to svg Result of export to svg by Apache OpenOffice.
Created attachment 58940 [details] 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.
Created attachment 58943 [details] 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.
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
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)
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.
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.
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.
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.
With all the patches merged to libreoffice-3-5-2 - should this be closed ?
*** Bug 47590 has been marked as a duplicate of this bug. ***
Verified in 3.5.2rc2
*** Bug 48443 has been marked as a duplicate of this bug. ***
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
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
@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?
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.
(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?
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
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
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.
Revert back to VERIFIED FIXED.
@Christopher We are not living in a very small world. When I receive a document from a customer written in 3.4.4, edit it with 3.5.2 and return it back, to that customer it will look like *I* broke it. Do you expect me to tell the customer they have an infrastructure problem? What you call an EoL version, another person will call 'stable'. Actually the problem here is a not very well thought through migration path from 3.4.4 to 3.5. The promise of the Open Document Format was that this would never be a problem again, since the format is standardized and would not be allowed to change in a direction that causes backwards compatibility problems. However now the standard has not changed, but the interpretation. Actually M$ with their ever changing format seem to do a better job in migrating documents and users to a newer product while maintaining backwards compatibility with slower adopters. Would it not be at least the minimum to warn system administrators of large companies that they may run into this problem before rolling out a new version? The release notes might be the appropriate place. Ferry
Ferry Toth, this bug is VERIFIED FIXED. Unless a code error exists in the patch, no more comments to this bug report are required. Regarding release notes, you are welcome to submit a new report advising of release migration issues. Thank you.
Hi, so is new bug report the right way to handle this? I have to agree 100% with Ferry breaking backward compatibilty is a huge disaster. For me affects 100's of legal documents and dozens of interal and external users whom we have already had a hard enough time convincing multiple IT depts to install. Only solution is forklift upgrade, really bad.
For some reason Korrawit set this to VERIFIED FIXED. Apparently that signals that we are not allowed to add comments on this situation any more. I think actually VERIFIED WONTFIX is more appropriate but don't dare to change it and risk pissing somebody off. oo.
(In reply to comment #34) > When I receive a document from a customer written in 3.4.4, edit it with 3.5.2 > and return it back, to that customer it will look like *I* broke it. > and > Actually M$ with their ever changing format seem to do a better job in > migrating documents and users to a newer product while maintaining backwards > compatibility with slower adopters. > and (In reply to comment #36) > For me affects 100's of legal documents and dozens of interal and external > users whom we have already had a hard enough time convincing multiple IT > depts to install. Only solution is forklift upgrade, really bad. > While I understand your frustration, there are several inaccuracies here I'd like to correct. First, conflating MS (or, for that matter, any *commercial* offering) with a free software / volunteer project is at best disingenuous. I'm certain any number of companies providing professional support for LibreOffice will happily backport fixes to the very version you're using - just as MS does with service packs for older products. Second, this bug *is* nasty, and it *does* affect all those people who faithfully implement ODF as-specified - so if you promote ODF, you cannot possibly ask us *not* to comply with it, can't you? And third, if you'd ask nicely, I could maybe stick a hidden config option into one of the upcoming 3.5.x versions, that would permit switching that back (no UI for that, though). That would be a separate enhancement request though.
Wait a minute this IS NOT a bug in pre 3.5 LO or OOo. I have files that go back a decade that have very complex geometries like these and there is no problem, NONE. I can open them in 1x, 2x and pre 3.5 the 3x series no problem. That includes OOo, LO and IBM Symphony. There was never a problem hundreds of documents. This IS a nasty bug in the specification that from my point of view needs to be fixed. Slavishly following the spec document. to break more than a decade of functionality is poor product management. The end user does not care that the specification is flawless beautiful only that the product work forward and back. The ODF file specification should be amended ASAP to match what every implementation has done to maintain continuity. Breaking that continuity is was loses user trust and confident, not mindlessly following the spec the end user be damned! The spec and the design do need to follow each other but that does not mean you never bend the spec to match the reality on the ground.
First off - please move this discussion to discuss@documentfoundation.org. To your question: (In reply to comment #39) > This IS a nasty bug in the specification that from my point of view needs to be > fixed. > No it's not. Did you read the spec? It is referring to svg in that particular section. Svg is not going to change, and I would strongly oppose deviating in subtle parts from that standard, to accomodate an implementation bug in _one_ ODF consumer. Please note further that with 3.5.3, we *do* correctly read old documents, and note even further that there's about a million other things that won't show up correctly in OOo 1.0, if you make it load a current ODF1.2-extended document. Get real.
Hello Thorsten, I am a big believer in free software and in standardization of document formats. First, if a commercial project introduces a bug, there is no way to have a discussion with the developers. With free software I can and that is, most of the time, refreshing. Second, we as a company need to keep our documentation available for at least 10 years after delivering the last product. That would mean for us at least for a period of 15 years after creating a document. That's why we choose ODF and PDF. Obviously the choice for ODF raises a lot of eyebrows internally and externally for us too, as skiani also mentions. The funny thing with standards is that it is not the writing of a standard that makes it a standard, but the adoption of it. So while former versions of OO and LO incorrectly implement it in some respects, that implementation has become the 'defacto standard' pure by market share - at least for now. I honestly can't say if this bug will hold up large scale adoption of > 3.5 (17 users subscribing to this bug only). And when everybody transitions, there will be no difficulties in exchanging documents between companies. In that respect exchanging doc's with MS Office users is a bigger issue. Creating a having config switch as you suggest would probably only have the effect of prolonging the transition phase as new doc's with the broken format would be created with each day passing, which is not would I would want either. It would probably have been better to add a fix to the 3.4.6 release, especially as that was as I understand for a similar reason, file compatibility of encrypted documents, but I guess that is now too late. Having a Save As OpenOffice/LibreOffice 3.3/3.4 option would work for me, but I guess building that, getting it tested and distributed would take so much time that it would be too late to help anyone? Otherwise I would ask you 'yes, pretty please, could you do this for us, ordinary but involved free software users'. Thanks for the attention, I will shut up now, see how the world adopts 3.5.x and then follow. Bye.
Related: bug 50704
*** Bug 48483 has been marked as a duplicate of this bug. ***
*** Bug 47699 has been marked as a duplicate of this bug. ***