Rename the masters template in Impress. We have more masters in the template. I want them named by purpose. Home page, Home page, Current page, final page Masters rename and save the template. After saving has one (usually the second in line - Home page) the same name as the name of the template file. It's a bug or intention?
Could you attach sample presentation to test? And please explain how to see the problem?
Created attachment 80187 [details] Presentation Open the template, I will choose to edit masters. Rename all Mastry as I need. Saved. Temporarily change how it stores records. After opening the template with 1 master name as the file name.
I'll try to figure it out: 1. Open attached file 2. Menu: View > Master > Slide Master 3. In 'Slides' pane on the left side we can see 4 masters with 4 different personalized names 4. Rename each master (by right clicking each master, then "Rename Master") 5. Save, close, & reopen that OTP file 6. See that name of 1st master fallback to previous name (occured on 2nd master at other attempt) Is that what you mean? Tested using LO 4.0.4.1 (Win7 32bit)
Yes, exactly. I guess it is not not clear from my English.(In reply to comment #3) > I'll try to figure it out: > 1. Open attached file > 2. Menu: View > Master > Slide Master > 3. In 'Slides' pane on the left side we can see 4 masters with 4 different > personalized names > 4. Rename each master (by right clicking each master, then "Rename Master") > 5. Save, close, & reopen that OTP file > 6. See that name of 1st master fallback to previous name (occured on 2nd > master at other attempt) > > Is that what you mean? > > Tested using LO 4.0.4.1 (Win7 32bit)
Ok lets change status to NEW :) Hope this isn't a duplicate of previously reported bugs.
I can reproduce this behaviour all the way back to LO 3.3.0, and it is also still present in OOo 4.1.1 Setting Version:Inherited From OOo Removing Whiteboard:bibisectRequest and Keywords:regression
This is OK in LibreOffice 3.3.4 any way. @Matthew, pls tell me what are you doing?
Created attachment 110445 [details] test file from LibreOffice 334 the attachment shows it works fine in 3.3.4
Created attachment 110446 [details] Screenshot of reproduction in 3.3.0 Please don't set the version forward. I can reproduce reliably on 3.3.0 See attached screenshot. Master slide 2 was renamed to "B", but this has been substituted with the filename on save
(In reply to Matthew Francis from comment #9) > See attached screenshot. Master slide 2 was renamed to "B", but this has Pls attach your file. My file shows it works fine in 3.3.4
Created attachment 110447 [details] File saved with 3.3.0 Attached. This file was produced by: 1) Opening the original file in 3.3.0 (OSX, 32 bit) 2) Renaming the master slides to "A", "B", "C" and "D" 3) Saving the file as an .otp again (under a new name) The name of master slide 2/"B" has been replaced with the filename as described in comment 3
Sorry, that should have been 'Renaming the master slides to "A", "B", "C" and "D" as described in comment 3' ... 'The name of master slide 2/"B" has been replaced with the filename as described in comment 2'
Created attachment 110450 [details] presentation from 330 created with attachment 110447 [details] Works fine in 3.3.0 for me. I rename the masterpage to NAME_B, I save as document, and reopen.. name is still OK. Maybe you hit a different problem?
set version to 3562 again.. I'm 100% sure also from my memory that this was not a problem in the past, somewhere
Created attachment 110451 [details] screen shot of my test result maybe superfluous ?
TESTING with LO 4.4.0.0.beta1 + Ubuntu 14.04 (In reply to ign_christian from comment #3) > I'll try to figure it out: > 1. Open attached file When opening the file, I get this error: --- A Scripting Framework error occurred while running the Basic script vnd.sun.star.script:UnicornTemplates.Main.Translate?language=Basic&location=application. Message: The following Basic script could not be found: library: 'UnicornTemplates' module: 'Main' method: 'Translate' location: 'application' --- > 2. Menu: View > Master > Slide Master > 3. In 'Slides' pane on the left side we can see 4 masters with 4 different > personalized names > 4. Rename each master (by right clicking each master, then "Rename Master") > 5. Save, close, & reopen that OTP file Get same Scripting Framework error as before when opening file. > 6. See that name of 1st master fallback to previous name (occured on 2nd > master at other attempt) The names I set did not stick, however the initial error seems very suspect to me. Is anyone else seeing that error?
(In reply to Robinson Tryon (qubit) from comment #16) > When opening the file, I get this error: > > --- > A Scripting Framework error occurred while running the Basic script > vnd.sun.star.script:UnicornTemplates.Main. > Translate?language=Basic&location=application. > > Message: The following Basic script could not be found: > library: 'UnicornTemplates' > module: 'Main' > method: 'Translate' > location: 'application' >... > > The names I set did not stick, however the initial error seems very suspect > to me. Is anyone else seeing that error? Yes. There is a macro linked to the action New document (Tools > Customise). I ignored this, because I think it's not related.
Another thing: I tested saving as ODP. Others as OTP. May have influence too. So maybe the saving of the names in OTP is partly broken already a long time, fully broken more recent, just as that in ODP..
Still a problem in 4.4 and 5.0.
Cor: Looks like you bumped up priority today -- justification?
(In reply to Robinson Tryon (qubit) from comment #20) > Cor: Looks like you bumped up priority today -- justification? It's a huge annoyance that this bug exists. Does that count :)
(In reply to Cor Nouws from comment #21) > It's a huge annoyance that this bug exists. To expand on that: it are the business man, account manager and sales type of people that I know complaining on Impress. It's a key-type of user that we need to win/keep on our side.
Tried bibisecting this problem, but the problem is present in the oldest of all bibests (43all oldest). The problems occures only when saved as ".otp", and not when saved as ".odp" So the bug is older then: http://cgit.freedesktop.org/libreoffice/core/commit/?id=d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 And can't bi bibesected with current bibesect-libs. (Removing bibisectRequest)
Barring a proper bibisect an exact first released version in which this was broken would be very helpful, e.g. with the "releases" OSX bibisect repo at: http://dev-downloads.libreoffice.org/bibisect/mac/Bibisect_MacOSX10.6%2b_release_lo-3.3.0_to_lo-4.1.tar.bz2 Comments 6-12 do not make that clear really. (Also note that sometimes, if a bug seems to work in one Version, that might be luck, not design. In that case its not a regression really.)
Migrating Whiteboard tags to Keywords: (bibisected prebibisect) [NinjaEdit]
*** Bug 97480 has been marked as a duplicate of this bug. ***
I confirm this bug on LO 5.0.4 and LO 4.3.7.2. My steps to reproduce: - Create a new Impress document - View > Master > Slide Master - Create and rename some master - Save the file as an .otp with "filename" - Observe that all the master have been renamed as "filename", "filename1", etc. Note that if there were a space in the file name, it's replaced by "%20" The renaming occurs at each saving. The renaming did not occur if saving as an .odp
I observed the same bug in Draw when saving as an .otg, works fine when saving as an .odg.
From http://downloadarchive.documentfoundation.org/libreoffice/old/ I installed the oldest LO version: 3.3.0.4. The bug is a bit different but still here: it only renames the first master, not the others ones. If I try to rename it after saving the file a first time, it renames it again.
Still looking for a concrete lead on this but I noticed something weird during my tests. It may be the expected behavior though. 1) View > Master > Slide Master 2) In the Side Bar (on the right), display Master Pages 3) In the Side Bar, put your cursor on the master in "Used in This Presentation" and observe the name of the Master. 4) On the left, rename the Master as you want. 5) Repeat action 3 and observe that the name didn't change. 6) In the Side Bar, display another section, then Master Pages again. 7) Repeat action 3 and observe that the name did change. I don't know if it's really relevant to this ticket but it affects the master naming.
After debug and analysis, the function originally rename masks in a template document is in the file ./libo-core/sd/source/ui/docshell/docshel4.cxx The method is : bool DrawDocShell::SaveAsOwnFormat( SfxMedium& rMedium ) This method has a side effect, she’s overwrite the mask name performed by the user. The most surprising in this method, that we are rename all masks name when the file name is valued. More, the file name « aLayoutName » is valued every time in the first part of this method : if( rMedium.GetItemSet()->GetItemState(SID_TEMPLATE_NAME, false, reinterpret_cast<const SfxPoolItem**>(& pLayoutItem) ) == SfxItemState::SET ) { aLayoutName = pLayoutItem->GetValue(); } else { INetURLObject aURL( rMedium.GetName() ); aURL.removeExtension(); aLayoutName = aURL.getName(); } The fact that the file name is everytime valued make useless the code in the second part of this method : if (!aLayoutName.isEmpty()) { sal_uInt32 nCount = mpDoc->GetMasterSdPageCount(PK_STANDARD); for (sal_uInt32 i = 0; i < nCount; ++i) { OUString aOldPageLayoutName = mpDoc->GetMasterSdPage(i, PK_STANDARD)->GetLayoutName(); OUString aNewLayoutName = aLayoutName; // Don't add suffix for the first master page if( i > 0 ) aNewLayoutName += OUString::number(i); mpDoc->RenameLayoutTemplate(aOldPageLayoutName, aNewLayoutName); } } Do you think that the code in if (!aLayoutName.isEmpty()) is still useful ? It should not be the reverse, do an action only when the file name isn’t valued ?
Anyone have any something to tell about this ? Best regards
(In reply to Alexis PAQUIN from comment #32) > Anyone have any something to tell about this ? Hi Alexis, Apparently not. And please realize that just looking and saying something useful may be very expensive. See the "Solving arbitrary problems..." presentation in this blog http://www.gnome.org/~michael/blog/2016-04-29.html. Ciao - Cor
*** Bug 99876 has been marked as a duplicate of this bug. ***
Hey, There here is, the gerrit path for this fix : https://gerrit.libreoffice.org/#/c/28750 Bests Regards. Alexis
sll committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e7446c7e7cef06c3f3aa2f19292a412944f0f8a3 tdf#62717 FILESAVE : Names Master pages are not saved properly It will be available in 5.3.0. 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.
thanks Alexis! Will check the next daily build.
works great indeed in master Version: 5.3.0.0.alpha0+ Build ID: 1ef48f3bebe80a386490e2a0f8fd0ae40de07ada CPU Threads: 4; OS Version: Linux 4.4; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-09-18_23:46:24 Locale: nl-NL (nl_NL.UTF-8); Calc: group thanks again!
Great ! :D Thanks you to all, i'm happy to contribute to fixed this issue.