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