It is common to highlight some words in a presentation, notably by using bold fonts and colors (at least for me). As far as I can tell, the presentation module doesn't have a GUI to select a character style so this has to be done manually, making it annoying to do and painfull to do in a consistent way, especially if we want to ajust the color later on. As far as I can tell, the corresponding ODF relies on "local styles" anyway, so the backend should already support character styles, only the GUI is missing: the Would it be possible to change the stylist used in the presentation and drawing modules to also show text styles (both paragraph and character styles)? Thanks!
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Thanks for bugreport with new idea > It is common to highlight some words in a presentation, notably by using bold > fonts and colors (at least for me). As far as I can tell, the presentation Please, attach presentation with described animation. Developers will see how it should be in presentation. And will improve UI for do it more handy.
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
Changing to NEW.
*** Bug 93709 has been marked as a duplicate of this bug. ***
I would definitely up-vote this enhancement request. I'm an engineering post-doc and I use chemical symbols all the time; I often need to indicate chemical charge states with super-scripts. The current super-script setting accessed by ctrl-shift-p is not desirable to me; I would much prefer a value for "raise/lower by" of 67% compared to the default value of 33% (I don't understand why this is the default, but that's a separate issue). In writer I could address this by creating a new character style and assigning it to a customized keyboard shortcut. However, I cannot do this in impress. This dramatically slows down by presentation preparation. Automating this process would be extremely helpful to me. Is adding support for character styles in impress a very difficult problem? If it's something simple that developers won't get to because it's not a high priority, then I would be happy to explore a code fix myself.
(In reply to Alex from comment #9) > Is adding support for character styles in impress a very difficult problem? > If it's something simple that developers won't get to because it's not a > high priority, then I would be happy to explore a code fix myself. Too many bugs & enhancements and too little hands :) It would be fantastic, if you would explore it https://wiki.documentfoundation.org/Development/GetInvolved You can join the developer IRC channel, if you get stuck: https://wiki.documentfoundation.org/Website/IRC
*** Bug 128810 has been marked as a duplicate of this bug. ***
*** Bug 137297 has been marked as a duplicate of this bug. ***
Regina, Mike: Is it possible to use PS/CS in Draw/Impress? Don't think so.
Created attachment 172326 [details] Presentation with custom styles for paragraph and characters The attached file has custom styles for paragraphs and characters. I have created the document by moving the styles from <office:automatic-styles> to <office:styles>. The ODF validator considers it as valid. PowerPoint shows it correctly. It has a custom character style for yellow background color and one for bold, and a custom paragraph style for first line indent. The presentation has a text box and a custom shape rectangle with text, that use these styles. So yes, ODF allows custom styles for text in shapes. But it is no only a part to be added in the UI, the whole implementation is missing in LibreOffice.
(In reply to Regina Henschel from comment #14) > It has a custom character style for yellow background color and one for > bold, and a custom paragraph style for first line indent. Don't get any character formatting. Please attach a screenshot too.
(In reply to Heiko Tietze from comment #15) > Don't get any character formatting. Please attach a screenshot too. As I said, "not implemented in LibreOffice". Open it in PowerPoint.
Created attachment 172334 [details] Screenshot from PowerPoint
From UX POV we entries in the sidebar tab for PS and CS with the usual tree of styles and access to the property dialogs via context and main menu.
*** Bug 142743 has been marked as a duplicate of this bug. ***
The inaccessibility/unavailability of character styles is a proper bug. This is obvious both from the comparison from PowerPoint by Regina, and in light of my argument in the now-duped 142743, which I'll let myself repeat here... In Impress, one definitely needs multiple paragraphs (and other slide objects) to have consistent style, and to be able to change that style for them all at once. But it is also the case that one may need sequences of text _within_ (different) paragraphs or slide objects to share a style, and to be able to change that style for them all at once. It is not an esoteric use-case to want to style: * Internet Links * Emphasized words/phrases * Source code keywords * Placeholder text * Inline quotations etc. So, marking this as a normal-severity bug.
(In reply to Eyal Rozenberg from comment #20) > The inaccessibility/unavailability of character styles is a proper bug. This > is obvious both from the comparison from PowerPoint by Regina, and in light > of my argument in the now-duped 142743, which I'll let myself repeat here... Please, not again. It seems you think this playing with severity will somehow speed up the development of things you care about.
(In reply to Buovjaga from comment #21) > Please, not again. It seems you think this playing with severity will > somehow speed up the development of things you care about. If you believe that it is not a bug for Impress to be without character styles, make your argument. Otherwise, please don't start an edit war. To your point - severity is what it says it is. IMNSHO, this issue is more severe than a potential enhancement, hence my change. It is also important to note that some of the issues marked duplicates are bugs rather than enhancement requests (and not just my own dupe - see bug 93709). When something is suggested as an enhancement, but it turns out that the lack of the "enhancement" is the cause what in itself is a problem, then - the issue is no longer just a potential enhancement. Whether this change leads to faster resolution is a matter of LO and volunteers' prioritization of tasks. Naturally one would expect that severity and number of duplicates factor into that to some extent, but this is secondary to representing the true state of affairs.
(In reply to Eyal Rozenberg from comment #22) > (In reply to Buovjaga from comment #21) > > Please, not again. It seems you think this playing with severity will > > somehow speed up the development of things you care about. > > If you believe that it is not a bug for Impress to be without character > styles, make your argument. Otherwise, please don't start an edit war. It is not a bug, because it is something that needs to be added. There is no need for a more nuanced argument, now please let the severity stay.
(In reply to Buovjaga from comment #23) > It is not a bug, because it is something that needs to be added. There is no > need for a more nuanced argument, now please let the severity stay. It is a bug, because it - when considering the contents of the dupes if not solely in itself - "an unexpected defect, fault, flaw, or imperfection": https://www.merriam-webster.com/dictionary/bug Now, it's true that it would perhaps be better for this system to track "issues" rather than "bugs" (as is the custom with Redmine, JIRA, GitHub, GitLab etc.), to avoid the overly-specific connotation you're insisting on, but - in actual use, both here on this server and on other bugzilla installations, "something that needs to be added" is often considered a bug.
Please no more this stupid game. None of dupes, nor this one, tell about "LO works differently to the way it's designed". They all tell about need to add something missing, and no matter how desirable it is, it is enhancement request. If someone wants to insist that those who actually work with this bug tracker (i.e., developers and triagers) suddenly start doing it differently because one person wants to shock everybody with their linguistic skills, that persom would better just keep off this bug tracker. Thanks.
(In reply to Mike Kaganski from comment #25) > Please no more this stupid game. You mean, no more except when _you_ play the "stupid game"? > None of dupes, nor this one, tell about "LO works differently to the way > it's designed". Of course they don't. They describe _bugs_, which is not the same thing as "working differently than designed". I listed the dictionary definition above. > If someone wants to insist that those who actually work with this bug > tracker (i.e., developers and triagers) suddenly start doing it differently That's what you you seem to want. People - both lay users, triagers and AFAIK developers - have been using it to file _bugs_, not just enhancement requests, about cases of unexpected and undesirable designed behavior, not just behavior different than the design. And it's been like this for years. I hope you are aware that I do my fare share of triage on LO. In fact, I just got a couple of congratulatory T-shirts and a bunch of stickers in appreciation of that work. So - your condescending tone is misplaced.
*** Bug 142751 has been marked as a duplicate of this bug. ***
*** Bug 82664 has been marked as a duplicate of this bug. ***
I've clarified the title to also cover paragraph styles. If anyone believes the two issues should be split (character vs paragraph) - feel free to do that.
On 2020-10-22 I've changed the Summary from [FORMATTING EDITING UI] Presentation module should support paragraph and character styles to [FORMATTING] Impress and Draw should support character styles (and maybe more paragraph styles?) For the following reason: formatting 'paragraphs' is basically provided for by the styles for Outline 1-10 and Header, that are part of each of the slide masters. But indeed, as you suggest Eyal, a separate issue for 'paragraph' styles might make sense.
(In reply to Cor Nouws from comment #30) > For the following reason: formatting 'paragraphs' is basically provided for > by the styles for Outline 1-10 and Header, that are part of each of the > slide masters. That's only true for the elements which are already present in the slide master, but is not true for paragraphs anything you insert into the slide: Extra text boxes, callouts, table cells etc. So, given that, and the wording of OP's first comment, and considering the example Regina created has both CS and PS's, are you sure we should separate the bugs?
So, I noticed Rafael Lima's dupe also requested list styles in Impress/Draw - which are also missing. I therefore repeat my question - for Cor, Heiko, Aurelian, Rafael and others: Should we keep this as a single bug for adding Character, Paragraph and List styles, or should we split it up? ... if nobody answers, I will: 1. Be disappointed 2. Create separate bugs for each of the three kinds of styles missing from Impress/Draw. 3. Create a meta-bug to track all of them and bug 151264 4. Close this bug as a dupe of the new meta-bug
(In reply to Eyal Rozenberg from comment #32) > Should we keep this as a single bug for adding Character, Paragraph and List > styles, or should we split it up? IMO fixing each of them (character, paragraph, list styles, etc) involves a lot of work and hence they should be considered separately. I think it's more likely that someone in the future will deal with paragraph styles and then someone else will tackle character styles. If we have just one ticket, then we may end up having a "too hard to fix" bug.
This ticket has received a lot attention (and is flagged as highly important therefore). Splitting it up has no benefit as the implementation of one styling likely brings also the other. My understanding is that we do have PS, yet limited, but not CS. But the question is ultimately up to the developers.
(In reply to Heiko Tietze from comment #34) > Splitting it up has no benefit as the implementation of one > styling likely brings also the other. Really? I mean, if we had Character Styles, would that give us List Styles? And Table Styles? > My understanding is that we do have PS, yet limited There's no UI for it, so we don't have it. Or - do you mean at the ODF level? > but not CS. And not List Styles, nor Table Styles. > This ticket has received a lot attention (and is flagged as highly important > therefore). Well, we could ameliorate this by also putting everyone on the CC lists of the relevant specific bug and the meta bug, and make comments on the dupe explaining what has gone where. I'm willing to do that. Alternatively, we could keep this bug as the meta bug.
(In reply to Eyal Rozenberg from comment #35) > (In reply to Heiko Tietze from comment #34) > > Splitting it up has no benefit as the implementation of one > > styling likely brings also the other. > > Really? I mean, if we had Character Styles, would that give us List Styles? > And Table Styles? We don't have real table styles to begin with: https://wiki.documentfoundation.org/Development/GSoC/Ideas#Implement_table_styles
(In reply to Buovjaga from comment #36) > We don't have real table styles... Maxim submitted a lot of patches recently to make TS shine in sd. See https://gerrit.libreoffice.org/q/owner:momonasmon%2540gmail.com Cannot find quickly the ticket about harmonization of TS between Writer/Calc and sd.
(In reply to Heiko Tietze from comment #37) > (In reply to Buovjaga from comment #36) > > We don't have real table styles... > > Maxim submitted a lot of patches recently to make TS shine in sd. See > https://gerrit.libreoffice.org/q/owner:momonasmon%2540gmail.com > Cannot find quickly the ticket about harmonization of TS between Writer/Calc > and sd. Better ref, see Mike's comment in https://wiki.documentfoundation.org/Development/Budget2022#Table_Styles_improvements
(In reply to Buovjaga from comment #36) > We don't have real table styles to begin with: > https://wiki.documentfoundation.org/Development/GSoC/ > Ideas#Implement_table_styles I know, and we really should... that's bug 151264, which is currently marked related to this one.
(In reply to Eyal Rozenberg from comment #32) > 1. Be disappointed If that helps, why not ;) > 2. Create separate bugs for each of the three kinds of styles missing from > Impress/Draw. Yes, please do. Wrt 'paragraph' styles, I think we need proper analyses on what makes sense in Impress/Draw.
The new meta-bug 152652 will track individual bugs for different style categories. *** This bug has been marked as a duplicate of bug 152652 ***
So, have split up the bug. I've added you all to the CC list of the new meta-bug (152652) - please add yourselves to the CC lists for the specific bugs of the style categories you're interested in following (Character, Paragraph, List, Table, Page/Slide).