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. ***