Ubuntu

Particular Subtracted shapes not compatible LibO 3.4 - 3.5

Reported by Ferry Toth on 2012-04-11
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
LibreOffice Productivity Suite
Fix Released
High
libreoffice (Ubuntu)
Undecided
Unassigned

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
---
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
DistroRelease: Ubuntu 11.10
InstallationMedia: Kubuntu 10.10 "Maverick Meerkat" - Release amd64 (20101007)
NonfreeKernelModules: nvidia
Package: libreoffice 1:3.4.4-0ubuntu1
PackageArchitecture: amd64
ProcEnviron:
 LANGUAGE=
 LANG=nl_NL.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 3.0.0-17.30-generic 3.0.22
Tags: oneiric
Uname: Linux 3.0.0-17-generic x86_64
UpgradeStatus: Upgraded to oneiric on 2011-10-13 (201 days ago)
UserGroups: adm admin cdrom dialout fax floppy lp lpadmin mysql mythtv plugdev sambashare scanner syslog users video

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.

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.

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
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
Source for the svg file.

Document generated with Apache OpenOffice.

Created attachment 58933
result of export to svg

Result of export to svg by Apache OpenOffice.

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.

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.

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

Created attachment 59654
Exalon Delft logo

Our company logo has been for a long time as in the attached drawing (odg).

In pre-3.5 if has always shown as in the ExalonDelftLogo 3.4.4.pdf.

Starting from 3.5 the original element that have been used to create the logo are displaced as shown in ExalonDelftLogo 3.5.pdf.

The same problems happen in 3.5.1.

Also, the problems happen in our Writer templates where we have this odg embedded (as an object).

Strange - are we the only ones suffering from this?

Ferry

Created attachment 59655
Exalon Delft logo as shown in pre 3.5 LibreOffice

Created attachment 59656
Distorted in 3.5 and at least 3.5.1

Ha, just found this bug to be resolved in LO 3.5.2 (verified with the Windows version).

Ferry

But not resolved entirely:

Opening Exalon Delft logo with 3.5.2 and saving it again, then opening in 3.4.4 shows the same type of distortion.

I don't think this bug can be closed yet.

Ferry

Modify Version due to Comments.

Reported problem not reproducible with "LibreOffice 3.5.2.2 German UI/Locale [Build-ID: 281b639-6baa1d3-ef66a77-d866f25-f36d45f] on German WIN7 Home Premium (64bit). But I can confirm effect from Comment 4

@Ferry Toth
Your OS?

OK, so this is the status:

The 'particular shapes' have been created a draw object with OO 3.2.1 and embedded in a writer document.
The have now been 'saved as a copy' draw document by LO 3.4.4.
Opening this using 3.5.0, 3.5.1 and 3.5.2 shows a broken drawing.
Opening with 3.4.4 shows no problems.
Saving again (without modifications) by LO 3.4.4 (this is the version I attached above).
With 3.4.4 no problem.
With 3.5.0, 3.5.1 broken.
With 3.5.2 displays OK.
Then saving with 3.5.2, opens in 3.5.2 without problem.
In 3.4.4 and 3.4.6 broken.

Versions used:
3.4.4 Ubuntu Oneric
3.4.6 W7 x64 native
3.5.0, 3.5.1, 3.5.2 Windows (native W7 x64, virtual box W7 i32 and x64)

To help reproduce the original problem I attached the freshly extracted embedded object ExalonLogo_embedded.odg.

This one displays well in 3.4.4 but not in 3.5.2.

Ferry

Created attachment 59790
Displays well in 3.4.4, distorted in 3.5.0, 3.5.1, 3.5.2

Extracted (save copy as ..) from a writer document using 3.4.4, originally created using 3.2.1 (?), but not opened / re-saved in 3.4.4.

Yes, "Displays well in 3.4.4, distorted in 3.5.0, 3.5.1, 3.5.2" perfectly show the problem, what is not fixed in parallel installation of Master "LOdev 3.6.0alpha0+ – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 4495824-6299bf6-ec8645]" (tinderbox: Win-x86@6-fast pull time 2012-04-08 00:03:52)

Alreadx a problem with 3.5.0RC2, still worked fine with3.5.0 Beta0

@Thorsten:
Please set Status to ASSIGNED and add yourself to "Assigned To" if you accept this Bug

Any chance this can be fixed in LO 3.5.3 (i.e. in a Ubuntu service release)?

Or do we need to wait for the fix to land in 3.6?

(I don't about other organizations, but in ours windows user are on OO 3.2.1 and Kubuntu users on LO 3.4.4. It would be very nice if we could all to use the same LO while still being able to open our old documents).

Ferry

Changed in df-libreoffice:
importance: Unknown → Medium
status: Unknown → Confirmed
summary: - Particular Subtracted shapes not compatible LibO 3.4 - 3.5
+ [Upstream] Particular Subtracted shapes not compatible LibO 3.4 - 3.5

This is a dupe, and should therefore be fixed in 3.5.2.

3.4.4 is broken, and can't retroactively be fixed. I don't know how relevant this is in practice, potentially one could add a hidden config item "export broken svg", or tie it to ODF1.0/1.1 export (though I'd hate that - it is indeed written wrongly).

*** This bug has been marked as a duplicate of bug 47406 ***

*** Bug 48443 has been marked as a duplicate of this bug. ***

I don't know what you mean by '3.4.4 is broken'?

We are creating and editing documents with OO 3.2.1 and LO 3.4.4 intermixed without having this problem. Problems start with 3.5.0 and occur also in 3.5.2.

So it is either not fixed in 3.5.2 or has existed from at least from 3.2.1 until 3.4.4.

Considering the amount of documents created in that period of time, I don't think it is reasonable to say 'it is fixed in 3.5.2'.

Unless you have a workaround to work on 3.5.2 documents with OO 3.2.1 and LO3.4.4?

Something more elegant then: export it to MS doc.

Ferry

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

Changed in df-libreoffice:
status: Confirmed → Invalid

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

Changed in df-libreoffice:
importance: Medium → Unknown
status: Invalid → Unknown

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.

Ferry Toth, thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command, as it will automatically gather debugging information, in a terminal:
apport-collect 979320
When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

description: updated
tags: added: oneiric
Changed in libreoffice (Ubuntu):
status: New → Incomplete
summary: - [Upstream] Particular Subtracted shapes not compatible LibO 3.4 - 3.5
+ Particular Subtracted shapes not compatible LibO 3.4 - 3.5
Changed in df-libreoffice:
importance: Unknown → High
status: Unknown → Won't Fix

apport information

tags: added: apport-collected
description: updated
Changed in libreoffice (Ubuntu):
status: Incomplete → New

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.

Changed in df-libreoffice:
status: Won't Fix → Fix Released

(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 <email address hidden>.

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.

wontfix as per upstream

Changed in libreoffice (Ubuntu):
status: New → Won't Fix

*** Bug 48483 has been marked as a duplicate of this bug. ***

*** Bug 47699 has been marked as a duplicate of this bug. ***

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.