When editing documents and wanting to have a strong control over formatting, I've found Microsoft Word's style guides feature highly useful. Here's a screen shot of the feature in use, found with Google Images: http://common3.ziffdavisinternet.com/util_get_image/23/0,1425,i=235534&sz=1,00.jpg Implementing it could 1) Provide useful functionality 2) Make it easier for Microsoft Word users to adopt LibreOffice.
[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
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
Well, the automatic edit done on this report is wrong. I wonder for how many which this is true.
It is true for ~700 Status changed to NEW
*** Bug 50516 has been marked as a duplicate of this bug. ***
Hello LibreOffice Developers, This functionality/feature enhancement request, if implemented, would significantly contribute to the migration of users from Microsoft Office to LibreOffice. The synchronised Style pane is one of the most useful features of Microsoft Word, and is extremely handy for debugging the meta-structure of word documents - a 'logical structure debugger', if you will. Please refer to the equivalent feature enhancement request for OpenOffice, and the commentary therein: https://issues.apache.org/ooo/show_bug.cgi?id=76667 This is what the synchonised style pane looks like in Microsoft Word: http://www.bettersolutions.com/word/WXX433/LR910331212.htm One could also envisage a page element panel as well, displaying page, section, header and footer characteristics, synchronously. Part of a fully general, *synchronous*, dockable, multi-pane 'logical structure debugger'. It would be the cat's miaow, the ant's pants, the bee's knees and the banana's pyjamas, in no fixed order. :-) Thank you for your attention. Yours faithfully, Brian Westlake.
Changed some bits...
Thank you very much Florian. It will be removing a major disincentive to migrate from MS Office.
With the implementation of experimental Sidebars functionality, in LibreOffice 4.1.0, from the IBM Lotus Symphony Office codebase, it might have become easier to implement this feature. The sidebar does have a style panel, however it is not the functionality provided by the microsoft style area as previously described. Given that the Sidebars work in single page view, would there not be the possiblity of having both left and right sidebars (either none, XOR, or both)? If so, could not the microsoft functionality be implemented in a right sidebar? On the road to a fully optioned logical (meta-)structure debugger. :-) Thank you for your attention, LibreOffice developers.
Dear Libreoffice Developers, Admittedly a "bump". However this link provides a neat summation of the "Reveal Code" functionalities of Microsoft Word (and WordPerfect), including the "Style Area", which is the specific functionality of this feature request: http://wordfaqs.mvps.org/revealcodes.htm A fully fledged "Logical Structure Debugger" integrating the best from Word and WordPerfect, and eclipsing both, for Writer would contribute strongly to the uptake of Writer from Word users, in particular. Thank you for you attentions. Best regards, Brian Westlake.
I like the idea of having a visual indicator in the document margin to give a visual feedback of the applied style. Makes it easier to format the document. However, it's not necessary to copy Microsoft, so I changed the summary a bit.
Created attachment 153684 [details] Mockup Here is a (first) mockup. It adds the request of nested styles (bug 115311 c5) that makes a combination of paragraph and character styles necessary and the styles inspector from bug 112852, see also bug 90646). And takes also bug 94427 into account (see comment at the styles inspector). The actual requirements for all those tickets are: * Eve wants to use paragraph and character styles to properly format the document. * Eve wants to get insights to applied styles to format the document consistently. * Eve wants to apply styles easily meaning to organize, sort, and filter the lists. * Eve wants to see what properties a style has to make sure the applied variant is correct. While the mockup in bug 115311 shows more or less all properties, I went here with the difference to the parent style to cover with the limited space. That means Default would always have no information in the style indicator. Drawback is that some special children of Text Body, for example, with just have one different property list only this particular value. For the document, it's a bit confusing to highlight character styles, eg. "Slowly" has a background color (direct formatting here, shown as gray overlay), which would spoil the yellow indicator. The only ultimate solution is to also have character styles at the left "indicator line", toggled with paragraph information. I don't think that's a good solution, however.
Very nice, thanks for the mock-up, Heiko. I've two general concerns. First, character styles are indicated within the text, paragraph styles in the margin. I'd prefer to show both in the margin, maybe character styles only as a line with the third of the width of paragraph indicator? (The whole paragraph style indicator is e.g. red and there is a character style in one line for which a yellow indication is visible in the margin that is as high as the line and has a third of the width so that in this line the indicator is red in two-thirds and yellow in one-third. If there is a second character style in the same line, the character indicators takes two-thirds of the space. Paragraph + 1. character + 2. character style. If there are more character styles in the same line, they share at maximum the two-thirds of the space. I doubt there will be so much character styles in a line that this results in indicators with hairbreadth. ;) ) Second, paragraph indicators should have strong colors and character styles should have pastel colors. But are there enough colors to show all possibilities in a document? We've soooo much pre-defined styles ...
Well, as long as users can turn it off. For most use cases it is a bit overkill - IMHO :)
(In reply to Cor Nouws from comment #17) > For most use cases it is a bit overkill - IMHO :) that will be true. In addition if you have this colorfull layout what do you do with it? is it to review style usage. Most users don't care about styles. Would it be more helpful to use an mockup language layout. for example you have something like <h1>First chapter</h1> <p>He heard quit steps behind him. .... <i>particular moment</i>, just after he pulled off the <b>big time</b> and was making off ... or any other mockup language like markdown or latex. with syntax highlighting it gave an good overview and you can change stuff like in an text editor.
andreas_k - you just reinvented "reveal codes" from Wordperfect :)
(In reply to Tomaz Vajngerl from comment #19) > andreas_k - you just reinvented "reveal codes" from Wordperfect :) See bug 34002 ;)
(In reply to Thomas Lendo from comment #16) > I'd prefer to show both in the margin, maybe character styles > only as a line with the third of the width of paragraph indicator? There could be more than one character style in one line. So it would be many lines next to each other. The mixing approach, 1/3, 2/3 etc., sounds a bit complex to me. > Second, paragraph indicators should have strong colors and character styles > should have pastel colors. But are there enough colors to show all > possibilities in a document? We've soooo much pre-defined styles ... Guess we have to randomize the colors. And what's missing in the indicator bars is a number to not only rely on the color. Doesn't work with my way to highlight character styles. (In reply to andreas_k from comment #18) > Would it be more helpful to use an mockup language layout. Isn't the markdown/reveal code approach the opposite of feedback to the WYSIWYG document? I mean you enter (a few) styles to the document - and we have formatted it. Point here is to get an overview and understanding of what is applied and how styles are defined.
> (In reply to andreas_k from comment #18) > > Would it be more helpful to use an mockup language layout. > > Isn't the markdown/reveal code approach the opposite of feedback to the > WYSIWYG document? I mean you enter (a few) styles to the document - and we > have formatted it. Point here is to get an overview and understanding of > what is applied and how styles are defined. Maybe its the other way around, but this is a complete new ui scenario and mockup languages + highlighting is an well known approach from coding, html editting, ... for me mockup language support is the link between latex users, coders and an office suite. I am thinking more like webinspector tools from firefox and chrome. Split the content into text and styles into an separate view.
Created attachment 153832 [details] Revised mockup Here is the revised version. Colored variant has now also numbers to not only rely on colors. And I added a B/W version according Andreas' comment. Pure mark-up means to read the raw document that contains this information. For example, just a little bit stripped for only style information: <style-name="Heading_20_1">First chapter</text:h> <text:style-name="Text_20_body">He heard quiet steps behind him. That didn't bode well. Who could be following him this late at night and in this deadbeat part of town? And at this <text:style-name="T4">Emphasis</text:span></text:p>, just after he pulled off the <text:style-name="T4">big time</text:span> and was making off with the greenbacks. Was there another crook who'd had the same idea, and was now watching him and waiting for a chance to grab the fruit of his labor?</text:p> <text:style-name="Caption">Or did the steps behind him mean that one of many law officers in town was on to him and just waiting to pounce and snap those cuffs on his wrists?... Mark-up is not for humans ;-). At least not when it goes beyond <b>/<i>.
Putting such information into the comment margin will conflict with ordinary comments. This area is too small anyway. I see also problems with adding rectangles to the page margins. You would need to touch a lot of code, to distinct them from other graphic content. So I do not like that idea at all. But I support Andreas' idea of a separate inspector window similar to those known from DOM inspectors. It has the advantage, that it needs no code integration, but can be provided purely as extension. Such window would allow a more detailed view on the inheritance of properties. For example, a portion of text can have a direct format "yellow", a character style with "italic", which is derived from a character style with language set to "German", and uses the font height of the paragraph style, which inherits the font itself from the default style. And such window can be freely positioned and sized.
(In reply to Regina Henschel from comment #24) > Putting such information into the comment margin will conflict... Comments go to the right document margin, the indicators are at left (at least for LTR). Where exactly do you see the issue?
Then I do not understand your mockup. I thought the blue parts show the character formatting of the marked text part.
(In reply to Regina Henschel from comment #26) > Then I do not understand your mockup. I thought the blue parts show the > character formatting of the marked text part. I took the formatted dummy text example as available in this extensions [1] as prototype. This dummy text has comments for testing purpose. Changes are only made to the left margin and the content. Didn't I write some text?
[1] https://extensions.libreoffice.org/extensions/formatted-dummy-text
*** Bug 127708 has been marked as a duplicate of this bug. ***
(In reply to Heiko Tietze from comment #15) > t's a bit confusing to highlight character styles, eg. > "Slowly" has a background color (direct formatting here, shown as gray > overlay), which would spoil the yellow indicator. Maybe consider the possibility of suppressing text-highlighting when enabling style indicators?
Created attachment 154693 [details] Alternative mockup MikeK suggested to separate the two workflows. The highlighting is supposed for cleaning up while the inspector shows the reason of the actual layout. I recommended in bug 127708 to have the ability to remove single properties from a style in this inspector but changed my mind. Better we provide an interaction to go to the paragraph or character style dialog and have some means there than overloading this widget. So right click (or some tiny button on top as well) opens the respective dialog.
(In reply to Heiko Tietze from comment #31) > I recommended in bug 127708 to have the ability to remove single properties > from a style in this inspector but changed my mind. Better we provide an > interaction to go to the paragraph or character style dialog and have some > means there than overloading this widget. So right click (or some tiny > button on top as well) opens the respective dialog. I support this with a button to open the corresponding style dialog tab.
Changing priority back to 'medium' since the number of duplicates is lower than 5
*** Bug 133258 has been marked as a duplicate of this bug. ***
I tried clearing direct formatting from the paragraphs with different layouts and it had no effect.
Please ignore my last comment: I thought I was applying it to bug 133258. I will note in passing though that often when I view the HTML produced from Writer (or if I delve into the XML), I find long sequences of various kinds of text styles that are all the same, sometimes in sequences, sometimes nested. The style changes have no perceptible effect (they're just "no-ops") and merely complicate the structure. So if that structure was revealed by some kind of "show codes", it would reveal the "under the rug" complexity. My feeling is that much of the complex structure seems to be caused merely by editing the text - as if runs of text are broken to allow new text to be inserted (or deleted), even though there is no change in style. But that's just my intuition, based on knowing I haven't applied direct formatting, simply changed my mind about phrasing, or adding or removing information.
Anshu committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/172f589471edcac9a4974132a3145b721942879a tdf#38194 related: introduce StylesList control It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Two issues: 1. What turns this color-coding on? 2. What about people with different kinds of color blindness? Patricularly Green-Red? Is it possible to control the palettes somehow?
(In reply to Eyal Rozenberg from comment #38) > 1. What turns this color-coding on? The patch is just a minor step ahead. It separates the internal logic from the visualization. The color coding comes later.
(In reply to Heiko Tietze from comment #39) I wasn't asking about the patch, but in general. What _should_ turn the color-coding on? ... looking at the mockups again - is it supposed to be the "highlight styles" checkbox?
(In reply to Eyal Rozenberg from comment #40) > (In reply to Heiko Tietze from comment #39) > > I wasn't asking about the patch, but in general. What _should_ turn the > color-coding on? ... looking at the mockups again - is it supposed to be the > "highlight styles" checkbox? Yes, this checkbox is supposed to turn on the color coded bars in the document margin.
(In reply to Heiko Tietze from comment #41) > Yes, this checkbox is supposed to turn on the color coded bars in the > document margin. Well, in that case, there needs to be some bike-shedding about its text, because it's a bit confusing. It could mean "styles for highlights". Also it takes up vertical real-estate, which may be in short supply if the styles bar gets split in two. But I'm just pointing this out as something to consider later on.
No further input from UX needed.
A question about the second mockup: Are the comments with the style names supposed to be part of this feature? i.e. will the style indicator add comments with style names? Otherwise, they're a bit confusing.
(In reply to Eyal Rozenberg from comment #44) > A question about the second mockup: Are the comments with the style names > supposed to be part of this feature? i.e. will the style indicator add > comments with style names? Otherwise, they're a bit confusing. The Styles Indicator has been implemented and went into an extra deck. Don't get "comments with style names". If you mean the yellow stickers, it's just an annotation for the mockup, if you talk about the comments in the document, those come from the dummy text (in creates a document with as much features/formatting as possible).
This is just for Writer, right?
Hello, I am early, non-technical, commentator, from the early years (2013, 2014) of this feature request. I was wondering if the feature was anywhere near being fully implemented in a public release? Thank you.
*** Bug 151707 has been marked as a duplicate of this bug. ***
Created attachment 186697 [details] paragraph style and character style and direct formatting highlighting demo Hi All, Patch to realize paragraph style and character style and direct formatting highlighting is here for code review: https://gerrit.libreoffice.org/c/core/+/150451 Please see attached video for a demonstration of the patch.
(In reply to Jim Raykowski from comment #49) > Created attachment 186697 [details] That is a nice piece of work, will be a great enhancement. Thanks Jim!
Nice work! A few points though... * The diagonal stripes pattern is too "bold" IMHO. I'd consider decreasing its strength, e.g. by a transparency like effect, i.e. stripe color = eps * original color + (1 - eps) * black. * Repeating my question about controlling the color palette * Will it be possible to highlight only _some_ of the styles?
Created attachment 186749 [details] Demo of border, hatch pattern, and feature name changes Attached is a demo of changes made to the patch to: - show no border around DF and CS - make the hatch line color less dark - increase the hatch line spacing - use 'Spotlight' in place of 'Highlight' Also shown is placement of the UNO control used to show character directed formatting. The patch does not include an icon for the UNO or add it to any toolbar or menu. Design team assistance please.
(In reply to Eyal Rozenberg from comment #51) > Nice work! Thanks! > * The diagonal stripes pattern is too "bold" IMHO. I'd consider decreasing > its strength, e.g. by a transparency like effect, i.e. stripe color = eps * > original color + (1 - eps) * black. I agree. Is what is shown in the second demo better for you? > * Repeating my question about controlling the color palette > * Will it be possible to highlight only _some_ of the styles? Noted for future enhancements.
I dislike the DF separation from CS/PS+PDF. Users need to fully understand the formatting to deal with all these options. Maybe it would be easier to handle if we had a menu button, eg. next to the 'Show non-printable characters' icon, named for example 'Spot formats' which offers a couple of checkboxes including * "All formatting" (checking all below), * "Direct formatting" (it's one important use case to show all places where character attributes got changed, see bug 106556; I think users expect this to include PDF too and we could do without the colored variants of PS), * "Paragraph Styles" and * "Character Styles". Most users are probably not aware of CS, haven't tried to switch from the PS view to CS if checking the Stylist at all, and do DF only (also for the whole paragraph).
(In reply to Jim Raykowski from comment #53) > I agree. Is what is shown in the second demo better for you? Yes :-) > > * Repeating my question about controlling the color palette > > * Will it be possible to highlight only _some_ of the styles? > Noted for future enhancements. Sure. The thing is, it might be the case that the user is particularly interested in two or three specific styles, and those get assigned similar colors - since we assign so many colors - making transitions easy to miss.
(In reply to Eyal Rozenberg from comment #55) > it might be the case that the user is particularly interested in two > or three specific styles... One solution is to change the colors but IMO much more effective to uncheck/hide the spotlight for all other styles. Something for a future enhancement, if really needed.
Hi all, Has consideration been given to how this implementation will work with other UI interfaces, such as the Tabbed UI, in comparison to the standard (default) LO interface? Thanks and regards, John
(In reply to John Mills from comment #57) >... > Has consideration been given to how this implementation will work with other > UI interfaces, such as the Tabbed UI, in comparison to the standard > (default) LO interface? >... Looks to be agnostic for any of the MUFFIN UI. All controls are in the SB Styles deck so will work the same for any NB. Might need customize entry to check box enable "Spotlight Character Direct Formatting" for the Notebookbar. Would look better on the NB and TB if we can design an icon (the tooltip would be localized).
(In reply to Heiko Tietze from comment #54) > I dislike the DF separation from CS/PS+PDF. Users need to fully understand > the formatting to deal with all these options. Maybe it would be easier to > handle if we had a menu button, eg. next to the 'Show non-printable > characters' icon, named for example 'Spot formats' which offers a couple of > checkboxes including > > * "All formatting" (checking all below), > * "Direct formatting" (it's one important use case to show all places where > character attributes got changed, see bug 106556; I think users expect this > to include PDF too and we could do without the colored variants of PS), > * "Paragraph Styles" and > * "Character Styles". > > Most users are probably not aware of CS, haven't tried to switch from the PS > view to CS if checking the Stylist at all, and do DF only (also for the > whole paragraph). No, I think Jim got this right--with style focus via the SB deck controls only. They do not belong on the Menus & TBs (and can't be added effectively to the NB). The DF visibility toggle (as for bug 106556) is actually satisfied by this. Although I think the character DF UNO really belongs as a checkbox on the Styles -> Character content panel. I.e. everything provided from the SB. This will facilitate an "Eve" user working from the 'Fomatting (Styles)' TB with the Styles SB deck enabled--having as now customized the DF toggle UNO to the TB--they'd toggle to see why their layout is affected (better if checkbox toggle from the Styles -> Character content panel). But they'd otherwise leave the DF spotlights off and layout with styles rather than DF. "Benjamin" users would not be as concerned with styles in general, so the DF toggle UNO with just icon and tooltip can go to 'Standard' TB and probably the 'Format' menus. With the customize checkbox for the NB users that choose to work with the SB.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4bc86f6477c3ed5f0e97b0a530acf7e102b613b3 tdf#38194 tdf#106556 Enhancement to highlight direct formatting, It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jim Raykowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2ff85183b959c05134a2737d6d14afd1882f2ba3 tdf#38194 Use a hashed string HSL color approach It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Using the name Spotlight will cause confusion: https://en.wikipedia.org/wiki/Spotlight_(Apple)
(In reply to Buovjaga from comment #62) > Using the name Spotlight will cause confusion: > https://en.wikipedia.org/wiki/Spotlight_(Apple) I'm not a fan of "spotlight", but note that it can't be highlight. So we would need a different term. "indicators"? "indicator bars"?
(In reply to Buovjaga from comment #62) > Using the name Spotlight will cause confusion: > https://en.wikipedia.org/wiki/Spotlight_(Apple) (In reply to Eyal Rozenberg from comment #63) > (In reply to Buovjaga from comment #62) > > Using the name Spotlight will cause confusion: > > https://en.wikipedia.org/wiki/Spotlight_(Apple) > > I'm not a fan of "spotlight", but note that it can't be highlight. So we > would need a different term. "indicators"? "indicator bars"? As a checkbox label on the Styles SB deck "Spotlight" is perfect. There is no chance it would be confused with the Apple macOS Spotlight search feature. Likewise the "Spotlight Character Direct Formatting" toggle widget that can be user customize placed on menu (fits nicely under the Format -> Clear Direct Formatting entry) or on a toolbar (good at the end of the Formatting (Styles) TB). Leave it alone!
(In reply to V Stuart Foote from comment #64) > As a checkbox label on the Styles SB deck "Spotlight" is perfect. There is > no chance it would be confused with the Apple macOS Spotlight search feature. To me, it's not about the users confusing it inside the interface, but more about making it easier to discuss the feature in our community without creating confusion (search in Bugzilla, discussion in various channels...), saving us some frustration in the future. May I suggest "Annotate" instead? It's more descriptive, and "Label" is not available.
(In reply to Stéphane Guillou (stragu) from comment #65) > (In reply to V Stuart Foote from comment #64) > > As a checkbox label on the Styles SB deck "Spotlight" is perfect. There is > > no chance it would be confused with the Apple macOS Spotlight search feature. > > To me, it's not about the users confusing it inside the interface, but more > about making it easier to discuss the feature in our community without > creating confusion (search in Bugzilla, discussion in various channels...), > saving us some frustration in the future. > > May I suggest "Annotate" instead? It's more descriptive, and "Label" is not > available. I poked Italo just now. See if he offers a take on it. Otherwise, more so than "Annotate" --which it does with the style index values and color coding-- a simple "Show styling" label adjacent to the "Show previews" would identify what the checkbox will do. But then so does "Spotlight" as intransitive or figurative verb--exactly Apples usage for naming their search engine.
Thanks Jim!
I like the term, but something like "Spotlight" is IMO kind of hard to translate to other languages as it's generally used as a universal term. My guess is we should more look at terms like "Visualize" or a more simple "Show", if one insist on using a single word to describe the function of the checkbox. That would be also more in line with the description in Word as shown here https://bug-attachments.documentfoundation.org/attachment.cgi?id=131974 From a usability perspective, as there is not so much space in the sidebar, I suggest "Show examples" and "Spotlight/Show/Visualize" should not be on the same line but better off be on separate lines. That would make room for a more consistent and descriptive "Show examples" and "Show in document".
(In reply to Sebastiaan Veld from comment #68) > I like the term, but something like "Spotlight" is IMO kind of hard to > translate to other languages... Mind to create a new ticket? There have been discussions left and right about the name and it would be good to collect it.
*** Bug 153308 has been marked as a duplicate of this bug. ***
https://help.libreoffice.org/latest/en-US/text/swriter/01/spotlight_styles.html Well, that is, most certainly, a thing of joy and beauty to behold, in LibreOffice v7.6.0 Writer. Thank you very much to all of the developers involved. Best regards,