[Upstream] Impress disregards Master Slide settings saving to .odp

Downstream bug may be found at:
https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/641175

1) lsb_release -rd
Description: Ubuntu Natty (development branch)
Release: 11.04

2) apt-cache policy libreoffice-impress
libreoffice-impress:
  Installed: 1:3.3.1-1ubuntu4
  Candidate: 1:3.3.1-1ubuntu4
  Version table:
 *** 1:3.3.1-1ubuntu4 0
        500 http://us.archive.ubuntu.com/ubuntu/ natty/main i386 Packages
        100 /var/lib/dpkg/status

3) What is expected to happen is when one performs at the Terminal:

loimpress -nologo

click Next button -> Next Button -> Create Button -> View -> Master -> Slide
Master -> Format -> Page... -> In Page Setup window (notice Orientation has
highlighted Landscape radio button) Width 5.51" -> Height 2.68" -> Ok button
-> In Master View window Close Master View -> Insert -> Slide -> File -> Save
As... -> Name example -> File Type ODF Presentation odp -> Save button -> File
-> Exit -> Perform at the Terminal:

loimpress -nologo example.odp

Insert -> Slide
The new page has the same configuration as the Master Slide.

4) What happens instead is now the box extends downwards vertically below the Master Slide settings.

For Thorsten?

Also having this issue with lo3.3.1 on ubuntu 32 bit.
When closing/reopening the document the master page content zone kept setting itself to adjust with text.
It made master slide unusable in my use case, so I had to install oo3.3 instead to continue working.

Could anyone have a look as this issue?
This prevents me from using libreoffice, so still on oo3.3.
I'm setting Importance to Normal instead of minor: loosing settings when saving is not a minor issue, data is lost!
Thanks

fmjrey, this issue is currently assigned to <email address hidden>. If you want to collaborate on development feel free to shoot an E-Mail. Issue confirmed in Ubuntu 10.10, LibreOffice Impress 3.3.2.

lsb_release -rd
Description: Ubuntu 10.10
Release: 10.10

apt-cache policy libreoffice-impress
libreoffice-impress:
  Installed: 1:3.3.2-1ubuntu2~maverick1
  Candidate: 1:3.3.2-1ubuntu2~maverick1
  Version table:
 *** 1:3.3.2-1ubuntu2~maverick1 0
        500 http://ppa.launchpad.net/libreoffice/ppa/ubuntu/ maverick/main i386 Packages
        100 /var/lib/dpkg/status

Changing from medium normal to high major because this bug:
- causes data loss: settings from master slide are not saved
- causes the loss of a major functionality: master slide cannot be changed
Would be great if this bug could get the attention it deserves.
Thanks.

I'd like to confirm that this bug is still present in 3.4.3. I cannot alter existing master slides at all. This makes it cumbersone to create new Impress presentations from scratch.

I have got nearly the same bug on my system (Fedora 16 x86_64) but the box is not getting too big but too small.
Changing system to all
Changing version to LibO 3.4.5 release.

Thank you

The issue persists in LibreOffice 3.6.2.2.

Please note that there have been several duplicate reports in recent months. I don't have permission to mark them as duplicates, so I will list them here:

Bug 55720, 53340, and 54005.

I will note this on the duplicated reports, but ultimately someone should merge the above.

voltaic, please do not toggle the Version. For more on this, please see http://wiki.documentfoundation.org/BugReport_Details#Version .

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

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

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

Reproducible in:
Microsoft Windows Vista Business x86 6.0.6002 Service Pack 2 Build 6002
Version 4.0.0.1 (Build ID: 527dba6f6e0cfbbc71bd6e7b88a52699bb48799)

Just made a test. The problem reported in
https://bugs.freedesktop.org/show_bug.cgi?id=55720
still exists in LibO Version 3.6.5.2 (Build ID: 5b93205) on XP/SP3.

As this bug has been confirmed to be in LibreOffice 4 as well, going to move forward with making this a MAB3.6.

3.5 is at end of life in its cycle and therefore will get no more updates. We are trying to close the 3.5 most annoying meta bug.

In general I wouldn't agree that this is a MAB as it just doesn't affect enough people BUT since it's been on the list for nearly a year I'll go ahead and push it forward to the 3.6 MAB list. We'll try to push this one forward ASAP.

Thanks for your patience, apologies it's taken so long

Thanks for pushing it forward. This bug is always cumbersome because it slows people down.

I will investigate the bug.

It seems, that the changes in the master slide are stored correctly in the styles.xml, but they are not visible after saving and reopening the file.

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

I had a recollection that you did some master-page fixing recently David - was this a duplicate ? :-)

Are the fix already pushed to master? With a build from monday I can still reproduce the bug.

As far as I can tell there is no fix yet. You'll see an automated message when the fix is committed to master

The cause for this bug lays in following method (xmloff/source/draw/ximpstyl.cxx):
void SdXMLMasterPageContext::EndElement()

It gets called when the XML element "style:master-page" in styles.xml is closed. That means that the master page is completely parsed. In the EndElement method ((SdXMLStylesContext*)pContext)->SetMasterPageStyles(*this); is used to set all default styles for the master page. The problem is that all user modifications are already applied and are overwritten with this call.

A near idea is to set the default styles when creating the master page and than apply all customizations. So I moved the SetMasterPageStyles call to the constructor of the SdXMLMasterPageContext class (entering of the XML element "style:master-page"). This solves the problem with the size of the outline object, but it breaks the font. The size of the font used in the master page are not set correctly.

My knowledge about libreoffice is too limited, to distinguish if I fall from one bug into another one, or if this behaviour is reasonable.

Any hints/feedback how to handle this bug is welcome ;)

My knowledge about libreoffice is too limited to fix this bug. Every approach I tried break some other stuff, so feel free to grab this bug.

Joel: Assumming that nobody is actually working on it or has any
plans to do it soon (see comment 24) are you willing to change status of this bug back to NEW?

I cannot test to reproduce this bug. So I ask the original reporter if he still experience it on recent LibO versions like 4.0.4 and 4.1.0

The bug exists still in LibO 4.1.0.4 (tested on windows 7)

Just open a new presentation, change the slide size to A6 and save the document. Now close the document and open it again. When you now create a new slide the text box is too big. Or just look at the master slide ;)

@mohofmann
thanks for your confirmation.
I'm gonna move this from mab3.6 to mab4.0 since 3.6.x branch is no longer supported.

The bug still occurs at Libreoffice 4.1.0.3-2.fc19

This was triggered by http://cgit.freedesktop.org/libreoffice/core/commit/?id=aa9af08b389a106fcfb53842ac7669b208a27205 specifically the sd/source/core/stlpool.cxx rSet.Put( SdrTextAutoGrowHeightItem(FALSE) ); line which causes the xmloff to call some reset property stuff on import which causes the box to recalculate itself as mhofmann describes

Did some testing in 4.1.1.2:

One slide
One master slide
Change width of both text boxes is master slide.
Back to normal view.
   > changes not visible.

Create new masters slide also with different width for text boxes
Back to normal view.
Apply MasterPage2
   > changes not visible

However ... the changes do show in the preview of the master slides...

Now add a slide
   > has MasterPage2 applied
Apply first master page
   > Only one of the text boxes is changed

Now add third slide
  > both master pages can be applied there and show all changes

The funny thing is, that for the first and second slide the behaviour is still the same, as described above :D

This is still happening in the 4.1 release, both for 32- and 64-bit Intel processors.

This should be considered a really major error -- it's really hard to work with templates if your sizing isn't kept.

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

https://gerrit.libreoffice.org/#/c/5887/ "works for me(tm)" for the original problem of the initial report.

Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=14e7a290dab7fead66ef6ff7f94c6a425d80ceb6

Resolves: fdo#34987 skip autoheight reset if it will be set to the same value

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.

Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=0964a73d03bf9f5b9f485ff39f97c7e7b54339b3&h=libreoffice-4-1

Resolves: fdo#34987 skip autoheight reset if it will be set to the same value

It will be available in LibreOffice 4.1.3.

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.

Fixed in 4-1 and 4-2, proposed in gerrit for 4-0 and 4-1-2

Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=19a9dda3ec36874d337de65364c265946c7004df&h=libreoffice-4-0

Resolves: fdo#34987 skip autoheight reset if it will be set to the same value

It will be available in LibreOffice 4.0.6.

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.

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

tested in 4.1.3.2 and found the bug is gone.
Thanks to all who worked on the fix!