Bug 62175 - FORMATTING: Style information lost after slide copy
Summary: FORMATTING: Style information lost after slide copy
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
(earliest affected) release
Hardware: Other All
: high critical
Assignee: David Tardon
Whiteboard: BSA
: 71471 82815 (view as bug list)
Depends on:
Reported: 2013-03-11 15:03 UTC by Markus Michels
Modified: 2015-02-19 05:28 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Markus Michels 2013-03-11 15:03:29 UTC
Problem description: 

Objects do not keep their assigned format style and revert back to default making some presentations useless, at least unpredictable

Steps to reproduce:
1. Create new doc in Impress
2. Define two custom styles and make some visual changes for ease of recognition and differentiation
3. Create a new slide
4. Add some boxes and contents, apply the two newly defined styles to new boxes / objects
5. Save the document
6. Create a duplicate of slide by using the right click duplicate function
7. Create a duplicate of slide by using ctrl-c / v combo
8. Create empty slide and copy all objects (not the slide) from first slide by ctrl-c / v combo
9. Save the doc and close Impress
10. Reopen the doc and be surprised
11. First page is fine, last page (empty slide with copied objects) is also fine
12. The two slide copies (duplicate and ctrl-c/v) have same objects with different styles - they are now default style

Current behavior:
See above - object styles get lost and revert back to default under certain conditions

Expected behavior:
Objects keep their assigned styles, no matter how they have been created.
Operating System: Ubuntu
Version: release
Comment 1 Joel Madero 2013-04-22 17:05:44 UTC
for step 2, what kind of style? When I push F11 and get into styles and formatting text I see graphic style and Presentation styles....I assume you mean presentation style, in which case, I am unable to create a "new" style here....perhaps a new regression?

Can you test on release - this is the latest release of LibreOffice

Marking as NEEDINFO, let me know if you're even able to create a new style, if not, we have a regression (if you can confirm you can make a new style in release) and that new regression would block this bug as I can't even confirm it.

Once you confirm these points please mark as UNCONFIRMED and I will report a new bug if it's needed
Comment 2 Markus Michels 2013-04-22 23:22:04 UTC
Dear Joel,

thanks for taking care of my bug report, since I believe this is a real nasty one.

I am referring to a "Graphics Style", i.e. I create a box, define and assign a custom graphics style, change some settings (e.g. colors). When I then copy the entire slide, after closing and reopening the doc the box on the copied slide has lost its custom graphic style information.

Furthermore: I am on the latest version ( and the bug still exists.

Thanks for your great effort into this great product,

Comment 3 flamingdescent 2013-06-20 22:54:14 UTC
Hello Markus,

I can reproduce this bug on Windows 7, LibreOffice (The objects I used were rectangles made from the Drawing toolbar.) Therefore, I changed the Status to NEW (which means it's a confirmed bug).

This bug has a workaround (copying and pasting the individual objects rather than the slide), but the user can still copy and paste the slides without any indication (besides after closing and reopening the document) that the styles are going to be lost. So I marked the importance of this bug as "high critical" (a component that affects many users and data loss).

Thanks for reporting this bug!
Comment 4 David Tardon 2013-07-15 13:34:39 UTC

*** This bug has been marked as a duplicate of bug 41436 ***
Comment 5 Markus Michels 2013-07-31 03:40:54 UTC
Style management seems to be very broken since LO 4 I must say... I just files another bug which renders this product virtually useless. Since 4.1 Impress even loses style information upon saving the document and there is nothing I could do about it. Please also consider bug 67565.

Thanks in advance and regards,

Comment 6 Markus Michels 2013-11-04 15:24:45 UTC
(In reply to comment #4)
> *** This bug has been marked as a duplicate of bug 41436 ***

I am not entirely sure if this is really a duplicate... because copying or moving entire pages in Impress with objects and custom styles applied still lose those styles and they revert back to "default" style. Style management is one of the key USPs of impress over Powerpoint to ensure consistency within and across documents. This bug makes the product useless for people heavily relying on this feature. I checked LO 4.1.3, and this bug is STILL present.

Is there a viable chance that it will be addressed anytime soon? As I mentioned earlier there are quite a few glitches in formatting / style management that seem to be introduced with version 4 (such as no negative indents, custom styles that cannot be deleted or renamed, embedded SVG graphics get crippled from to LO, but not between OO and MS PPT...). This is a core feature of that product and I would appreciate if this could get highest possible attention for near future releases. As for myself I can safely say that robustness beats new features... personally I do not miss any features, just robustness.

Any takers?

I don't want to be mean, I really do like this product in general and really appreciate all the effort of all you pros are putting into it. But I would be happy to see a shift in priorities (robustness), because as of right now I am forced to work with OO 4.0.1.

Thanks and regards,

Comment 7 Markus Michels 2013-11-29 12:22:55 UTC
Bug seems to be fixed in LO 4.2.0 Beta 1 Linux x64
Comment 8 Markus Michels 2013-11-29 13:17:48 UTC
sorry, NOT fixed... just checked again
Comment 9 retired 2014-01-01 11:26:56 UTC
*** Bug 71471 has been marked as a duplicate of this bug. ***
Comment 10 Markus Michels 2014-08-04 17:42:48 UTC
This one is flagged as high critical, but I haven't seen any changes recently.

Is this bug goind to be addressed anytime soon?

Cheers and regards,

Comment 11 QA Administrators 2014-08-04 17:45:30 UTC
The status + importance is just guidance for developers. Developers volunteer to fix bugs - so we do not give ETA's
Comment 12 Regina Henschel 2014-08-19 23:11:55 UTC
*** Bug 82815 has been marked as a duplicate of this bug. ***
Comment 13 Regina Henschel 2014-08-19 23:16:33 UTC
The error happens, if the formatting of the shape is done using a style. For the copied shape the style is correctly highlighted in the Style&Formatting-window, so that you think the style is applied. But in the saved document the attribute "style:parent-style-name", which should reference the style, is totally missing and so this information is lost.

@David, the issue is assigned to you. Are you working on it?
Comment 14 David Tardon 2014-08-20 13:56:19 UTC
@Regina, it fell off my radar... But I have time to look at it now.
Comment 15 bschussek 2014-09-09 08:49:55 UTC
I can confirm the bug for LibreOffice 4.3 on Ubuntu. Right-Click->Duplicate and copy-pasting the slide itself causes the bug and already messed up quite a few of my presentations.

The suggested workaround, i.e. creating a new slide and copy-pasting the contents of the other slide works.

This is really annoying.
Comment 16 Joel Madero 2014-09-09 14:21:10 UTC
Please refrain from comments that add nothing to the bug report itself. "This is really annoying" is a good way to demotivate our VOLUNTEERS. If it is annoying for you, there are indeed options: (1) fix it yourself; (2) find a friend, family member, colleague to fix it; (3) pay for a fix; (4) wait for our incredible volunteers to fix it when they have the time . . . Libre is not limited to "free" - it means you as an individual are empowered to become part of the project.
Comment 17 Markus Michels 2015-02-19 05:19:47 UTC
This one seems to be fixed in version 4.4

THANKS A BUNCH, really appreciate (either for active fix or magic happening).


Comment 18 Joel Madero 2015-02-19 05:28:56 UTC
@David - I'm closing this one as WFM as the original reporter says he can no longer reproduce the bug. If you are still working on it feel free to set it back to assigned. Thanks!