Problem description: I've created a screencast to demonstrate the need for this feature here: https://www.youtube.com/watch?v=6fdPIAPM_Pc Essentially, for designers to be able to produce excellent and really usable slide deck templates, we need more custom editable fields to be allowed in the slide masters. In the example video, I show how there are more fields typical in slide decks that the default set (only Title and a plain text box are provided for autolayout) of styleable master slide text blocks aren't enough. In the example, I have customer name, a subtitle for the presentation, and the presenter's name (which is sometimes the same as the author, but may vary especially for multi-presenter slide decks.) As a designer, I'd like to lay those fields out and style them for the users of my templates as well. Today that is not possible. The workaround is to create sample slides, style the text on those slides using filler text and hope the template users don't muck with the styling too much. The problem is, though, as soon as template users add a new slide, the slide is going to default to the autolayout sample text provided by the slide master, so I as the designer can no longer suggest full layouts for them. If the master slide could house styled additional custom fields, then new slides created using the same slide master would inherit them and the experience for designers and template users would be much improved. I have used LO to create such documents in LO Writer - it allows for the creation of arbitrary custom fields that users of my LO Writer templates can fill in the data for and have the styles already laid out and set up for them. I don't understand why those menu options are missing from LO Impress. If it was possible to implement it similar to how LO Writer does - including allowing for control of the sample text (E.g., "Type your name here." <= that kind of thing) then it would be excellent. Operating System: Fedora Version: 4.2.3.3 release
Hi Máirín, thanks for the ideas here. I understand that Insert > Fields offers too little possibilities. As a work around for time being, you can add more text to your (custom) master pages.
Hi Cor, as I explained in comment 0, adding text to the masters will not work, because that text will apply on every slide that uses the master and will not be editable by users. E.g., say I have a master, we'll call it 'MASTER A.' I put the following text on 'MASTER A': Presentation Title Subtitle Customer Name Case Study Text Product Used Now I have 5 customer case studies in my presentation; 1 slide for each case study. I create these 5 slides using MASTER A because that is the case study slide master design: SLIDE 1 SLIDE 2 SLIDE 3 SLIDE 4 SLIDE 5 Now slide 1 is for customer 1, slide 2 for customer 2, etc. The slides for each of them will look like the following with uneditable text: --- Presentation Title Subtitle Customer Name Case Study Text Product Used ---- I could go to the slide master and start filling that text out for customer 1. But then every slide, slide 1-5, will look like this: --- Customer Case Study Report Review session 4/30 ABC Company, Inc. ABC company needed to weeble their sprockets and peep their pops. Product: XYZ Sprockulator ---- Well, so now we have slides 1-5 displaying text for customer 1. That makes no sense either.
(In reply to comment #2) > > SLIDE 1 > SLIDE 2 > SLIDE 3 > SLIDE 4 > SLIDE 5 Fields make particularly sense for information that is put on more then one place, or more then two. So the given example with 5 slides and each different info for a special case, isn't a convincing argument for fields, is what I would say..
Hi, Maybe my specific examples aren't dead on. But I have definitely worked with presentations that use the same information on multiple slides - such as the presenters' names, the customer name, the subtitle, the product name that the slides are about, etc. etc. etc.
Also please consider that whether or not a chunk of text is repeated on multiple slides or just the master slide, the fact that the text is not variable means that a designer cannot produce a template that accounts for that separate piece of information.
Hi Máirín, (In reply to comment #4) > Maybe my specific examples aren't dead on. But I have definitely worked with > presentations that use the same information on multiple slides -.... Of course. My comment was not at all meant to disagree with your request !
For me, this is about giving presentation designers expanded functionality and flexibility in Impress for designing more useful presentation templates, and it's a feature that they're accustomed to using in proprietary presentation software: http://office.microsoft.com/en-us/powerpoint-help/add-a-text-placeholder-with-custom-prompt-text-HA010210725.aspx http://help.adobe.com/en_US/captivate/cp/using/WSd160b5fdf5100e8f-a0ae387126564aa2e8-8000.html#WS3d71e636065aa5be-3048b96a126ae8d0d56-8000
I support this request for several reasons: (1) The possibility to include custom fields will improve the flexibility of the creation of presentation templates as required data can be easily set using the File > Properties > Custom Properties dialog. (2) An implementation in Impress could make reuse of the code base of the Writer implementation of fields and thus lower the efforts connected with the realization of this feature request. (3) Since LibreOffice is seen as one software package from an end user point of view it makes sense to harmonize the features across the different LibreOffice components. That said, it is really not intuitive for an end user that the implementation of fields differs between Writer and Impress.
OK.. already reported *** This bug has been marked as a duplicate of bug 53548 ***
Cors, I really have to disagree that this is a duplicate of bug 53548 - that is a bug filed against Draw, not Writer, and involves Mail Merge of database content, whereas this doesn't involve database content. While the problem to solve is vaguely the same, that the applications are different should make them separate bugs, no?
(In reply to Máirín Duffy from comment #10) > Cors, I really have to disagree that this is a duplicate of bug 53548 - that > is a bug filed against Draw, not Writer, and involves Mail Merge of database > content, whereas this doesn't involve database content. While the problem to > solve is vaguely the same, that the applications are different should make > them separate bugs, no? Hi Máirín, 53548 is " Allow "Other" fields / DocInformation / custom editable fields in Draw/Impress (as in Writer) " and the summary of this bug " Allow custom editable fields as allowed in LO Writer " Component Impress.. So I do not see a difference..
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team Sun, 11 Sep 2016 12:29:16 +0200
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-20161010
*** This bug has been marked as a duplicate of bug 53548 ***