The specification explicitly allows nesting of <text:span> elements. Thereby character styles are put on top of each other without introducing an inheritance. Files where this is used work fine and in using hard formatting it works fine too. Only in using styles it fails and the surrounding style is removed. In testing for https://ask.libreoffice.org/en/question/144399 I noticed, that nesting is possible using shift+doubleClick in version Version: 6.1.0.0.alpha0+ (x64) Build ID: facfc2951ea9f4745edd4a6fb1cf97697f33f40a CPU threads: 8; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@62-TDF, Branch:master, Time: 2018-01-14_00:42:04 Locale: de-DE (de_DE); Calc: CL But that seems to work accidentally. So my request is, that a UI is added to put a character style on top of another by nesting <text:span> elements. There is likely a better method than shift+doubleClick, especially as accessibility has to be considered too.
Created attachment 139970 [details] Illustration of the issue "Suddenly..sidewalk" are formatted with Strong Emphasis, "disappeared" in the middle with additional Emphasis using shift+click and "the trash... in the" below as well in Emphasis but without shift, meaning it's replaced. The request is solely technically driven and I recommend to not do that. The redesign complicates the UI significantly with benefit in only a very few situations but serious disadvantage for most users. If we need to support these nested styles (my suggestion would be to remove them from the file format), the easter-eggy shift+click thing is good enough. But we should give better feedback as discussed in bug 90646, whereas I would prefer the inspector from bug 112852 comment 10. We should also not forget the "inconsistency" (actually I like it) mentioned on ask.libo that the Default style that is never nested.
(In reply to Heiko Tietze from comment #1) > The request is solely technically driven and I recommend to not do that. > ... > If we need to support these nested styles (my suggestion would be to remove them from the file format), the easter-eggy shift+click thing is good enough. I strongly disagree. The ability to nest character styles is extremely important for complex documents. It's the only sane way to represent semantic or formatting considerations that are orthogonal to each other. Style support is a widely touted feature of LO (and rightly so), but these kinds of limitations (can't nest character styles, can't inherit page styles, graphic styles not available in Writer, character styles not available in Impress...) prevents it from realizing its potential. Undocumented features are just as bad as not having the feature at all, unless you have unlimited time to tinker. I was extremely excited to learn that this might already work, because if true it's one less reason that I might need to use LaTeX. I never would have discovered it if not for Regina's exploration. Personally, I think a second "apply" button that nests rather than replaces existing styles would be an unobtrusive way to make nesting available. At the very least, the double-click feature should be confirmed and added to the help text.
(In reply to Kenneth Hanson from comment #2) > I strongly disagree. The ability to nest character styles is extremely > important for complex documents. It's the only sane way to represent > semantic or formatting considerations that are orthogonal to each other. Can we find a good example? Something like but better than: * in-text citation with highlighted words. "And she said:<i>Though shalt <b>NEVER</b> format directly!</i>, and went away." (<i> and <b> as html-like illustration of character style 'cite' and 'emphasis'). In the example you get NEVER in italic from cite plus bold from emphasis but I think a direct formatting would be fine here just for simplicity of the UI. When you present Change and Apply (or Add) I doubt that users understand that. Visualization could be done via tree where the second style is a children of the first (still not easy to understand).
Nested character styles are really cool. I also often wished that such feature is available in LibO. Good to hear that it's possible and that's also possible with buttons in the "Formatting (styles)" toolbar. But how long? How should nested styles be handled in the UI? LibO isn't prepared for this. How should nested styles (=several styles at once) be shown in the Styles sidebar? Or in the menu or context menu? There, character styles are now implemented as radio buttons (only one can be selected) which must be changed to checkboxes (more than one can be selected at once). And what's with the default character style? Does it override all nested character styles or only the "last/topmost" one?
Created attachment 141502 [details] Mockup for nested styles including comments Basically, the idea is to provide a multi-selection in the character styles list (same idea was suggested back in OOO times). Such a modification involves questions on single/double click activation of styles (bug 94427), requires a way to indicate overridden properties (done per style inspector, see bug 112852), which in turn is relevant for bug 90646. And also how paragraph styles are filtered (bug 114886, bug 69551). See comments in the mockup for details.
Very nice mockup. I see the benefit of a list box instead of buttons for all kind of styles (paragaph, character, list ...). For the average users it's more intuitive and clear. But with any style change you have to do an additional mouse click. That's bad for users that heavily use styles. Also I think the small paragraph and character boxes are negative for heavy style users. Is this really so much better for the average users? Will they better understand the difference between paragraph and character styles, when they are arranged/visible at one sidebar deck at once instead how it is now?
(In reply to Thomas Lendo from comment #6) > But with any style change you have to do an additional mouse > click. That's bad for users that heavily use styles. Like today, the selection changes with the context. So if you are in a table you get table styles selected. So no additional click needed. > Also I think the small paragraph and character boxes are negative for heavy > style users. True, we loose some space even taking into account that mockups are not proportional and the UI may have more space on average screens. We focus on the Benjamin users, which definitely benefit from the combination. And the supposed way for expert users who need a lot of paragraph styles at once is to collapse the character styles panel. We could also discuss to collapse the inspector by default.
(In reply to Heiko Tietze from comment #7) > supposed way for expert users who need a lot of paragraph styles at once is > to collapse the character styles panel. We could also discuss to collapse > the inspector by default. The possibility to collapse paragraph/character/inspector panel (which should also persistent across sessions) is an important feature for Eves. The filter options 'Preview...', 'List used styles...' and the filter drop-down list is also important for character styles - or work the filters for both panels at once? If yes then the position can be enhanced to show that. Is it desired to show how styles are nested? A new filter checkbox 'Show nested styles' can show only nested styles in a hierarchical way to see which is on top of what style.
Curious about Csongor's opinion.
(In reply to Heiko Tietze from comment #9) > Curious about Csongor's opinion. Thanks, Heiko. :) Before going into further details, I would like to clarify for the readers like me, who do not read carefully at first, that we are talking about the character styles only, not the paragraph and other styles. Well. There are some bullet points to agree/disagree with. 1. I agree that having the option to build a hierarchy of character styles is a great thing. We should not get rid of it, even if most of the users don't use it. One source of the power of LO is that it is extremely feature-rich. I would like to keep this and not make it "more streamlined" or "simpler" in terms of the feature set, like many "modern" software does. (The easiness of usage, however, is a different thing, I admit.) So let's keep features and based on this, let's figure out how to make it easy to use. 2. I agree that the UI for such complex document structures is not easy. 3. How should we indicate what styles are turned on at the actual character? I re-read my proposal in https://bugs.documentfoundation.org/show_bug.cgi?id=112852#c9. The illustration after that comment may be not the best but I still think that such a tool could explain well how the rules with higher importance override the rules of lower importance. The strike-through notation in the Developer Tools of the modern browser, I think, does this job very well. In order to make my earlier proposal easier to understand, I created a new illustration with a lot of verbal explanation within the document. Please, check it. Some keywords and highlights from the attachment so that it can be indexed: - applying more character styles (current and desired behaviour) - cascade - description of how the Style Explorer should work - greyed out and strike-through - toggling rules - drag-and-drop reordering of the character styles - "Select Similar", "Select Similar to Left" and "Select Similar to Right" toolbar buttons - "Extend Selection to Neighbourhood", "Extend Selection to Left Neighbourhood" and "Extend Selection to Right Neighbourhood" toolbar buttons
Created attachment 141973 [details] Explaining Cascaded Character Styles via Style Explorer
(In reply to csongor from comment #11) > Created attachment 141973 [details] Thanks a lot, great to have different proposals. I would prefer to not show all style properties (e.g. Default: Blinking=No), rather what's different to the used paragraph style, i.e. direct formatting. Your temporarily on/off feature sounds like an overkill to me and clutters the UI a lot with all these checkboxes (could be solved with a context menu, though). And last but not least it's not easy to understand the hierarchy without indentation. Admitted that your layout is more flexible and readable. Maybe we put some arrows in front of the list items pointing from bottom to top. But that's all my two cents and the discussion is open. (In reply to Thomas Lendo from comment #8) > The filter options 'Preview...', 'List used styles...' and the filter > drop-down list is also important for character styles - or work the filters > for both panels at once? If yes then the position can be enhanced to show > that. Correct, missed that. So we better group paragraph and character together as both are toggled with the kind of style anyway. And to clean up the UI I would think about moving the checkboxed options from paragraph styles into a context menu. > Is it desired to show how styles are nested? A new filter checkbox 'Show > nested styles' can show only nested styles in a hierarchical way to see > which is on top of what style. You mean in the character styles list?
(In reply to Heiko Tietze from comment #12) > (In reply to Thomas Lendo from comment #8) > > The filter options 'Preview...', 'List used styles...' and the filter > > drop-down list is also important for character styles - or work the filters > > for both panels at once? If yes then the position can be enhanced to show > > that. > Correct, missed that. So we better group paragraph and character together as > both are toggled with the kind of style anyway. And to clean up the UI I > would think about moving the checkboxed options from paragraph styles into a > context menu. But context menus are not very accessible/visible -- neither for normal users nor for impaired users. > > Is it desired to show how styles are nested? A new filter checkbox 'Show > > nested styles' can show only nested styles in a hierarchical way to see > > which is on top of what style. > You mean in the character styles list? Yes, I mean character styles. But when paragraph and character styles will share the same checkboxes, then no new checkbox is needed as paragraph styles already include a checkbox for hierarchical view.
I like Csongor's proposal very much! One thing though. The character's "Default Style" itself doesn't define anything at all. There are no settings there IIUC. And it is not always there at the bottom of the character properties hierarchy. Actually, Character-related settings of *Paragraph properties* are there, and those properties are what is being overridden by higher layers. And the Paragraph properties consist (from top to bottom in terms of Csongor's proposal) of paragraph's Manual formatting, and Paragraph style. The ability to *disable* (uncheck) some direct formatting or styles looks like an extension to ODF (at least I don't know how to disable that at the XML level). I'd suppose that deleting makes sense, an well as dragging style to reorder, and possibly dragging styles from style pane if they can be shown simultaneously. Possibly the default character style still makes sense as a (greyed out) single-line entry right above the Paragraph properties, to make it consistent when the last applied non-default character style gets removed, that one would still stay (instead of appearing only in that case). Possibly it also makes sense to delete direct formatting of paragraph's character-related settings from the character settings explorer. That would make it more universal. And of course, being able to launch the related style's editor dialog is something intuitive.
*** Bug 127754 has been marked as a duplicate of this bug. ***
*** Bug 128553 has been marked as a duplicate of this bug. ***
Don't remember the state in 23018 but with v7.3 at least it is possible to make one CS inherent from another by drag and drop at the Stylist. We also have the "Inherit from" field in the Organizer tab. And the nested CS takes attributes from the parent. So all works similar to PS. Regina, resolve WFM or am I missing a point?
(In reply to Heiko Tietze from comment #17) > Don't remember the state in 23018 but with v7.3 at least it is possible to > make one CS inherent from another by drag and drop at the Stylist. But that's not what this bug is about. It's about applying more than one character style to the same piece of text, not about styles inheriting from each other. See your own comment here: https://bugs.documentfoundation.org/show_bug.cgi?id=127754#c2
We discussed the topic in the design meeting. CS are typically a rare breed in text, using Emphasis and Strong Emphasis together has no real-world use case. What might be a use case, however, is a language, eg. a inline term in Latin should not trigger the English spellchecker, together with attributes to make parts outstanding. In any case it is possible to create a CS and inherit it from a parent. The procedure is well known from PS and easy to handle. No need to make the Stylist more complex. => WFM If, however, the stacked CS (to name it differently from nested aka inherited) is crucial in terms of applying more than one CS to the selection, it obviously could be done by multi-selection. Double-click wont switch from style A to B anymore but adds B to the applied A, and to disable A one needs to double click in order to toggle it off. We lose the feedback (or need to introduce it differently) for single-click selection of a style to just inspect or change. And the interaction of PS and CS would diverge.
(In reply to Heiko Tietze from comment #19) > CS are typically a rare breed in text ??? Is there any statistics? And if so - then that would be a definite sign of *insufficient* promoting of this kind of style, and would have nothing to do with this issue. > using Emphasis and Strong Emphasis together has no real-world use case. ??? There was only one person in this thread, who ever mentioned the nested "Emphasis" (before me quoting it here) - it's you. Why you introduce an invalid case first, and then dismiss it as invalid, as if this makes the expected *proper* use less valid? > What might be a use case, however, is a > language, eg. a inline term in Latin should not trigger the English > spellchecker, together with attributes to make parts outstanding. Well, that's just a sample of correct use. And actually, even if it would be really useful *currently*, ideally the language should *not* be part of the style, but part of the content, so with bug 151290, *this* specific use would be obsolete. What's more typical / intended is e.g. having a "quotation" style, and "emphasis" applied on some part of it - because you want to emphasize part of quotation. Any kind of combination of semantical styles may make sense; there are styles like "example", or "definition", and the users *should* create their own semantical character styles - and the impossibility to nest them would lead to geomertical proliferation of styles, like "quotation emphasis", "example emphasis", "definition emphasis", "quotation definition", "quotation definition emphasis", ... ??? > In any case it is possible to create a CS and inherit it from a parent. The > procedure is well known from PS and easy to handle. No need to make the > Stylist more complex. => WFM Now tell me, which style should that "quotation emphasis" inherit from - "quotation" or "emphasis"? And e.g., if your answer "from quotation": when later you decide to change "emphasis", you also have to not forget to change "quotation emphasis" manually (and also all the other "something something emphasis" as well)? is this the good workflow for the great "only change in one place" paradigm? And WFM is not applicable here, since WFM, as you know, is for some problem that was there, but later was fixed by an unknown commit (it's the same as FIXED, just without a knows commit). IMO, it would be nice if, before the meeting discussion, the feature would be used - at least by some who will discuss it, at least for a week, but really used, with possible "hey, I am testing your idea X; I don't understand this, or that, or ... - clarify it in the bug, so that the call discussion could have at least minimal sense"...
(In reply to Mike Kaganski from comment #20) > (In reply to Heiko Tietze from comment #19) > > CS are typically a rare breed in text > ??? Is there any statistics? APA7 for example "Italics for emphasis are acceptable if emphasis might otherwise be lost or the material misread; in general, however, use syntax to provide emphasis." What I mean is that you likely not have many different CS neither combinations of CS in a text. At least no use case has been presented here that requires to complicate the Stylist. Second part of comment 19 shares the idea how this could be done anyway.
(In reply to Heiko Tietze from comment #21) > APA7 for example "Italics for emphasis are acceptable if emphasis might > otherwise be > lost or the material misread; in general, however, use syntax to provide > emphasis." What on earth APA may have to do with this issue? Do you say that LibreOffice is a software to create papers to APA? Do you know that there are papers beyond science, and it sometimes happens that people, when finished their APA reports, write literature, poetry, children books, newspaper articles, and personal notes? So no - there are many cases with many different kinds of character-level formatting; and I just have presented a use case in comment 20. > Second part of comment 19 shares the idea how this could be done anyway. I'm sorry, I don't understand that. What is proposed exactly?
As I understand OP, there is a request for an improved UI to handling multiple CS applied to a text string. afaict, this point has not been part of today's discussion about this ticket. Therefore...the following point does not seem relevant to the OP... (In reply to Heiko Tietze from comment #21) > Second part of comment 19 shares the idea how this could be done anyway. ...because the issue is the UI, not how to do it. Meanwhile, today's discussion seems to revolve around whether "valid" (actual) use cases exist for multiple CS applied to a text string. (Heiko Tietze from comment #21) > What I mean is that you likely not have many different CS neither > combinations of CS in a text. At least no use case has been presented here > that requires to complicate the Stylist. Now that is curious, because Mike gave some examples... > (Mike Kaganski from comment #20) > there are styles like "example", or "definition", and the users *should* > create their own semantical character styles - and the impossibility to nest > them would lead to geometrical proliferation of styles, like "quotation > emphasis", "example emphasis", "definition emphasis", "quotation > definition", "quotation definition emphasis", ... ??? And fwiw....I do exactly what Mike describes. That is, I use some semantical character styles (e.g., category, theoretical concept, ontological object, technical word), and then I also did what Mike described -- making additional CS "category - intro", "theoretical concept - intro" , etc., so that I could add italics (where APA7 would also require use of italics for key terms or phrases for which you are going to provide a definition). I also have a CS called "maybe drop" and another "to be placed" (which I use to add a color to words that might be deleted from or moved in the text). Because I have not understood how to "nest" (or stack) the CS, then applying this CS replaces any of the semantic CSs that have been applied. (maybe this is easy to avoid, but it would be helpful if the UI could "afford" this better (e.g., tooltip, documentation). I am not claiming that these are valid use cases. I am just reporting them as some actual examples of what I have been doing for the past 4 or 5 years, without really knowing/understanding what I am doing. I find these possibilities interesting/useful (and started using them in the hope that they could even be practical once bug Bug 78582 is resolved, because then one could search for semantically identified words).
One more situation. When my semantic CSs are applied in a footnote, then the font size for the CS is applied, where it would be preferable that it was the fontsize of the footnote. (again, this might be a problem with my configuration, or maybe it shows situations where a semantic CS might be applied in a text where it might appear in the text body, a header, or a footnote, with different font sizes.)
First, some replies to some earlier comments; then reply to the conclusions from the design meeting in the next comment. (In reply to Heiko Tietze from comment #3) > Can we find a good example? Something like but better than: > >* in-text citation with highlighted words. * inline quotation with a publication title * article title which include an emphasized word * definitions which emphasize some words * definitions which mention the title of a publication * Internet link with an emphasized part-of-the-link * placeholder text with emphasized words > In the example you get NEVER in italic from cite plus bold from emphasis but I think a direct formatting would be fine here just for simplicity of the UI. Of course it wouldn't be fine here, because: 1. You'd have hunderds or thousands of occurrences of this DFing in your long document, which would get mixed with other DF. What happens if you want to search the highlighted words? Or you want to change formatting of word highlighting? 2. DF is bad for mechanized document analysis. (In reply to csongor from comment #10) > 2. I agree that the UI for such complex document structures is not easy. Yes, but think of, for example, the choice of font for different language groups. That's complex; and we've changed that relatively recently; and issues still remain with it. But - it's usable, and improving. > 3. How should we indicate what styles are turned on at the actual character? Any way is better than no indication. But as the simplest suggestion, and even before designing any UI for selecting/deselecting additional CS, we could at least: * Show a comma-separated list in the char style combo box * Show multiple selected items in the styles sidebar ... for documents which have multiple CSes applied.
(In reply to Heiko Tietze from comment #19) > CS are typically a rare breed in text Absolutely false. I use them in almost all Writer documents I author. (And I would use them in Impress too, except LO still wont let me; see bug 128810, which has multiple dupes from other people requesting it.) To the extent that people use DF over CSes for repeatedly-appearing formatting, that is due to mis-education: We are encouraged to use DF; it's the "junk food" of styling: Shiny, immediate satisfaction, no thinking about wider consideration and consequences, and when you have it a lot, it's bad for you :-) Also agree with what Mike said. > using Emphasis and Strong Emphasis together has no real-world use case. I just gave you six use cases, two of which I personally encounter frequently. > What might be a use case, however, is a > language, eg. a inline term in Latin should not trigger the English > spellchecker, together with attributes to make parts outstanding. Marking the term as Latin is the subject of bug 148257; and remember: language is not (or I should say: should not be) a formatting attribute, but an aspect of the content itself. > In any case it is possible to create a CS and inherit it from a parent. As Mike suggested, that's not a relevant solution. It's a bit like saying we shouldn't be able to mark text as underlined and as italic independently, with buttons, and that instead we would need to choose "underlined italic" from some combo-box with a zillion options. Moreover - style inheritance expressiveness is severely lacking in LO. We have (unfortunately) rejected being able to expressively inherit styles: bug 152712. One can't say any of the following: * "Font weight at 125% of the parent style" * "1 pt less inter-character spacing than in the parent style" * "font is bold if-and-only-if parent style font wasn't" > The procedure is well known from PS and easy to handle. That's a homunculus argument, Heiko, since it should also be possible to apply multiple Paragraph Styles at once: bug 149271. > If, however, the stacked CS (to name it differently from nested aka > inherited) is crucial in terms of applying more than one CS to the > selection, it obviously could be done by multi-selection. Yes. But - since users often like the selection to switch rather than to add, perhaps we would have an "enable multi-selection" toggle somewhere. > And the interaction of PS and CS would diverge. It should not, because what we do for CS we should do for PS as well (again, bug 149271).
Created attachment 196429 [details] Example text with nested character styles (In reply to Heiko Tietze from comment #19) > We discussed the topic in the design meeting. [..] > In any case it is possible to create a CS and inherit it from a parent. The > procedure is well known from PS and easy to handle. No need to make the > Stylist more complex. => WFM Inheritance is totally different from the situation I have described. My request is about nested <span> elements. You can have text <span italic> text <span bold> text </span> text </span> text. You can easily produce this with direct formatting. And you can produce it with character styles. But here you need to know, that you have to use Shift+DoubleClick instead of a simple DoubleClick. And how to do it without mouse? And when you set the cursor into word "switch" in the attached example, you get no information in the UI, which two styles are active. In the first example you see the other style before and after. But there need not be such text before or after a phrase, that has more than one style applied, see second "switch" in the attached example. Nesting <span> Elements is valid ODF, LibreOffice can handle it, but the UI for it needs improvement.