Bug 47406 - Almost all graphics that have internal circuits are not rending correctly.
Summary: Almost all graphics that have internal circuits are not rending correctly.
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.1 release
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard: target:3.6.0 target:3.5.2
Keywords: regression
: 47590 47699 48443 48483 (view as bug list)
Depends on:
Blocks: mab3.5
  Show dependency treegraph
 
Reported: 2012-03-16 05:02 UTC by skiani
Modified: 2013-06-19 09:45 UTC (History)
17 users (show)

See Also:
Crash report or crash signature:


Attachments
File created in 3.4.3 with series of examples of the problem. (36.34 KB, application/vnd.oasis.opendocument.text)
2012-03-16 05:02 UTC, skiani
Details
File created in 3.4.3, opened in 3.5.1 then saved. (38.25 KB, application/vnd.oasis.opendocument.text)
2012-03-16 05:04 UTC, skiani
Details
gdb session with backtrace from the warning (37.95 KB, text/plain)
2012-03-20 11:00 UTC, Terrence Enger
Details
Source for the svg file. (8.11 KB, application/vnd.oasis.opendocument.graphics)
2012-03-23 08:19 UTC, Regina Henschel
Details
result of export to svg (1.01 KB, image/svg+xml)
2012-03-23 08:21 UTC, Regina Henschel
Details
Tweaked svg from before (983 bytes, image/svg+xml)
2012-03-23 08:54 UTC, Thorsten Behrens (allotropia)
Details
Fix for the export problem (1.72 KB, patch)
2012-03-23 09:51 UTC, Thorsten Behrens (allotropia)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description skiani 2012-03-16 05:02:26 UTC
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.
Comment 1 skiani 2012-03-16 05:04:16 UTC
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.
Comment 2 s-joyemusequna 2012-03-16 12:34:18 UTC
Confirmed with LibO 3.5.1 on Windows XP. This is a regression.
Comment 3 Petr Mladek 2012-03-20 08:47:36 UTC
I add some draw developers into CC. Please, look at it ASAP. It would be great to fix this for 3.5.2-rc2.
Comment 4 Regina Henschel 2012-03-20 09:48:36 UTC
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.
Comment 5 Regina Henschel 2012-03-20 10:47:44 UTC
Build Build-ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735 (3.5.0rc3) is already faulty.
Comment 6 Terrence Enger 2012-03-20 11:00:57 UTC
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.
Comment 7 Muthu 2012-03-21 02:31:13 UTC
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.
Comment 8 Muthu 2012-03-21 02:33:34 UTC
CC'ing writer developers as well.
Comment 9 Regina Henschel 2012-03-23 01:55:14 UTC
Some new unfilled array heads are affected too, for example the unfilled triangle and the unfilled diamond.
Comment 10 Regina Henschel 2012-03-23 07:32:58 UTC
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.
Comment 11 Regina Henschel 2012-03-23 08:19:44 UTC
Created attachment 58932 [details]
Source for the svg file.

Document generated with Apache OpenOffice.
Comment 12 Regina Henschel 2012-03-23 08:21:25 UTC
Created attachment 58933 [details]
result of export to svg

Result of export to svg by Apache OpenOffice.
Comment 13 Thorsten Behrens (allotropia) 2012-03-23 08:54:23 UTC
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.
Comment 14 Thorsten Behrens (allotropia) 2012-03-23 09:51:29 UTC
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.
Comment 15 Not Assigned 2012-03-26 03:23:07 UTC
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
Comment 16 Not Assigned 2012-03-26 03:58:57 UTC
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)
Comment 17 Not Assigned 2012-03-26 04:06:34 UTC
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.
Comment 18 Not Assigned 2012-03-26 04:12:44 UTC
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.
Comment 19 Not Assigned 2012-03-26 07:51:31 UTC
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.
Comment 20 Not Assigned 2012-03-26 07:52:01 UTC
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.
Comment 21 Michael Meeks 2012-03-29 02:58:57 UTC
With all the patches merged to libreoffice-3-5-2 - should this be closed ?
Comment 22 Regina Henschel 2012-03-29 16:16:32 UTC
*** Bug 47590 has been marked as a duplicate of this bug. ***
Comment 23 Fridrich Strba 2012-04-03 06:58:47 UTC
Verified in 3.5.2rc2
Comment 24 Thorsten Behrens (allotropia) 2012-04-12 05:06:50 UTC
*** Bug 48443 has been marked as a duplicate of this bug. ***
Comment 25 Ferry Toth 2012-04-12 11:38:34 UTC
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
Comment 26 tommy27 2012-04-12 12:06:53 UTC
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
Comment 27 Rainer Bielefeld Retired 2012-04-12 13:14:36 UTC
@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?
Comment 28 Ferry Toth 2012-04-12 14:46:19 UTC
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.
Comment 29 Thorsten Behrens (allotropia) 2012-04-12 15:42:14 UTC
(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?
Comment 30 Ferry Toth 2012-04-13 07:34:53 UTC
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
Comment 31 Laurent Balland 2012-04-15 10:11:16 UTC
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
Comment 32 Chris Peñalver 2012-05-02 03:24:03 UTC
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.
Comment 33 Korrawit Pruegsanusak 2012-05-05 05:03:32 UTC
Revert back to VERIFIED FIXED.
Comment 34 Ferry Toth 2012-05-05 05:28:45 UTC
@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
Comment 35 Chris Peñalver 2012-05-05 05:42:21 UTC
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.
Comment 36 skiani 2012-05-05 06:14:16 UTC
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.
Comment 37 Ferry Toth 2012-05-06 08:35:55 UTC
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.
Comment 38 Thorsten Behrens (allotropia) 2012-05-07 04:32:12 UTC
(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.
Comment 39 skiani 2012-05-07 05:33:33 UTC
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.
Comment 40 Thorsten Behrens (allotropia) 2012-05-07 05:55:08 UTC
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.
Comment 41 Ferry Toth 2012-05-07 06:22:49 UTC
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.
Comment 42 Thorsten Behrens (allotropia) 2012-06-05 14:36:36 UTC
Related: bug 50704
Comment 43 Laurent Balland 2013-05-22 20:28:19 UTC
*** Bug 48483 has been marked as a duplicate of this bug. ***
Comment 44 ign_christian 2013-06-19 09:45:44 UTC
*** Bug 47699 has been marked as a duplicate of this bug. ***