It would be useful to have a comment style, as presently comments only utilize direct formatting and this cause quite a bit of problems for users wanting to format them. Ultimately a dev would have to let us know if this is even feasible.
Keep in mind that comments have a background depending on the user. But why is a style needed for comments? What use case do you have in mind beyond highlighting parts of the text.
This is about the text style in the comments having a configurable style or am i still not clear.
(In reply to Yousuf Philips (jay) from comment #2) > This is about the text style in the comments having a configurable style or > am i still not clear. Why would a user want to assign a style to comments? For instance: change all my comments from normal to italic. Sounds not plausible.
You have bugs that popup like these - bug 101214 and bug 102950.
I'd like to give an example from my actual work. I have a scientific document with almost 400 comments. There are different categories of comments: headlines for a single paragraph, explanations to the text, to-do-comments, critical questions, ... I use different colours to distinguish the different categories and I use different font sizes to distinguish the importance of the comments. So the possibility to assign every categorie of comments to a different style would be very helpful. By the way: Is there already a meta-bug for bugs and enhancements regarding to comments? I think it would be useful to collect those bugs.
(In reply to Dieter Praas from comment #5) > I'd like to give an example from my actual work... Thanks a lot, that makes the use case clear. +1 also from me now.
I wouldnt go so far as having multiple styles for comments, as comments arent meant to have such things, but want to be able to set some basic features that should affect all comments like the font name and font size. This wouldnt affect users adding direct formatting above this base style, though i dont think it is beneficial for users to modify the font name and size using direct formatting in comments.
Duplicate of Bug87057?
*** Bug 87057 has been marked as a duplicate of this bug. ***
Another example: I use comment boxes to mark essays, and if I could change the font of *all* of them at once to something skinny, then I can fit more comments in. Also, sometimes the comments on student essays (written in DOCX format, 90% of the time) end up double-spaced which means I have to manually change them back. Currently, you can change all the comments at once, but you can't make more changes once you've entered been direct formatting, so you have to wait until you're done the whole document to do it, which means you don't know if your comments will all fit.
Created attachment 132678 [details] See comment formatting in content.xml Now, every comment has its own character style (which are invisible for end users; I learned that for my research in bug 107095, comment 4). I would use that fact to keep work in this bug as easy/short as possible: - Handle comment styles as character styles in the character style list. - Initially, all comments should have the same default character style. - What's possible in character styles should be possible for end users to format comments. (In MSO Word 2013, the same (character) formatting is possible for comments as for normal text.) - If a user changes the formatting in a comment, a child character style should be created automatically for the formatted text. I know that comments with lists and other formatting is not possible with this solution. If this is requested, comments must be handled like normal text with the possibility to use all style types. In the attached test file I inserted 3 comments. All comments have the attribute text:style-name="T1" which is defined in the office:automatic-styles section of the content.xml file. The third comment contains text with bold formatting which has the attribute text:style-name="T2". The only difference between T1 and T2 is fo:font-weight="bold".
This seems reasonable! One "Comment" style that can be changed globally, no possibility of multiple styles within comment boxes. Thumbs up from me!
*** Bug 95267 has been marked as a duplicate of this bug. ***
(In reply to Thomas Lendo from comment #11) > Now, every comment has its own character style (which are invisible for end > users; I learned that for my research in bug 107095, comment 4). From what i saw in the xml file, this isnt accurate. Each character style combination has its own character style entry, but each comment has a paragraph style parenting all child text entries. <text:p text:style-name="P1"> <text:span text:style-name="T1">Ich bin </text:span> <text:span text:style-name="T2">noch ein Test</text:span> <text:span text:style-name="T1">.</text:span> </text:p> Unfortunately, the P1 paragraph style doesnt have font name and size assigned to them, so each character style has font name and size assigned to them. > I would use that fact to keep work in this bug as easy/short as possible: > - Handle comment styles as character styles in the character style list. Exposing each comment character style combination in the character style list would be useless to users. > - Initially, all comments should have the same default character style. This already happens. > - What's possible in character styles should be possible for end users to > format comments. (In MSO Word 2013, the same (character) formatting is > possible for comments as for normal text.) Ideally comments would have no formatting at all, this is how it is in Google Docs, or alternatively font name and size would be disabled, MS Word disables font size.
(In reply to Yousuf Philips (jay) from comment #14) > (In reply to Thomas Lendo from comment #11) > > Now, every comment has its own character style > From what i saw in the xml file, this isnt accurate. Each character style > combination has its own character style entry, but each comment has a > paragraph style parenting all child text entries. > > <text:p text:style-name="P1"> > <text:span text:style-name="T1">Ich bin </text:span> > <text:span text:style-name="T2">noch ein Test</text:span> > <text:span text:style-name="T1">.</text:span> > </text:p> > > Unfortunately, the P1 paragraph style doesnt have font name and size > assigned to them, so each character style has font name and size assigned to > them. You're right, so it's ridiculous working with character styles. The cleaner solution is to work with paragraph styles and only with character styles when necessary (for emphasis, etc.). The implementation now is absolutely weird. > > - What's possible in character styles should be possible for end users to > > format comments. (In MSO Word 2013, the same (character) formatting is > > possible for comments as for normal text.) > > Ideally comments would have no formatting at all, this is how it is in > Google Docs, or alternatively font name and size would be disabled, MS Word > disables font size. I agree that only a small set of features should be available for comments. As working much with comments, I really only need font, strong emphasis/emphasis and simple list features in comments. (Font because the default comment font changed somewhere in the past and I don't want comments with different fonts in a document. -- I simulate lists with "* Blabla" now.) I think there should be a paragraph style for all comments in a document with a small set of paragraph features available and very limited direct formatting if any. Use cases like in comment 5 need more than one paragraph style for different notations with various paragraph features. Before implementing a style there should be a consent of what features we want to be available in Writer comments and subsequently in other LibO components too.
Please note that it's extremely helpful to have font sizes supported, as comments can get very long, and reducing the font size is a good way to make more of them visible without having to click into them and scroll about, only able to see a small window onto it. Note also that people often will use a Symbol font thumbs up or down or smiley as a shorthand way of marking approval via a comment. You might also consider whether you could reuse the existing code for editing and display of text, from the full writer, rather than having to implement a separate text editor and text display algorithm.
(In reply to Luke Kendall from comment #16) > Please note that it's extremely helpful to have font sizes supported, as > comments can get very long, and reducing the font size is a good way to make > more of them visible without having to click into them and scroll about, > only able to see a small window onto it. I strongly agree to Luke. For most of my comments I use a size of 8pt. So I have the chance that most of the text is displayed in the margin without scrolling.
(In reply to Thomas Lendo from comment #15) > I agree that only a small set of features should be available for comments. > As working much with comments, I really only need font, strong > emphasis/emphasis and simple list features in comments. (Font because the > default comment font changed somewhere in the past and I don't want comments > with different fonts in a document. -- I simulate lists with "* Blabla" now.) We should likely decide what the optimal font size is for comment and not allow users to change it. We default to 10pt, MS Word uses 8pt, and Google Docs uses Arial 10pt. > I think there should be a paragraph style for all comments in a document > with a small set of paragraph features available and very limited direct > formatting if any. Use cases like in comment 5 need more than one paragraph > style for different notations with various paragraph features. The only thing i'd put into a comment paragraph style would be the font name and allow users to change it, so its not repeated in each character style. In comment 5's use case, I would suggest that a user can apply an existing document-level character style to a comment, but it would be a limited set of formatting options, and it wouldnt overwrite whatever default font size that are assigned to comments. > Before implementing a style there should be a consent of what features we > want to be available in Writer comments and subsequently in other LibO > components too. Yep we should do this. If we have a look at the formatting all comments character dialog, i'd say we should keep, font name, font style, underlining, strikethrough, overlining. (In reply to Luke Kendall from comment #16) > Please note that it's extremely helpful to have font sizes supported, as > comments can get very long, and reducing the font size is a good way to make > more of them visible without having to click into them and scroll about, > only able to see a small window onto it. That would be the wrong way to fix the issue of long comments. See bug 89232 for the discussion on how to improve that issue. > You might also consider whether you could reuse the existing code for > editing and display of text, from the full writer, rather than having to > implement a separate text editor and text display algorithm. The current implementation gives similar text editing features that are available in textboxes, as doing comments like text in full writer would be overkill.
(In reply to Yousuf Philips (jay) from comment #18) > (In reply to Thomas Lendo from comment #15) > We should likely decide what the optimal font size is for comment and not > allow users to change it. Disagree on the "not allow to change" aspect. Consider accessibility, additionally to the lengthy comments use case in c5. But of course it's neither a primary nor secondary function. So when your reason to descope a common property is based on simplicity it could be solved by hiding the function behind more relevant things.
(In reply to Yousuf Philips (jay) from comment #18) > (In reply to Thomas Lendo from comment #15) > > I agree that only a small set of features should be available for comments. > > As working much with comments, I really only need font, strong > > emphasis/emphasis and simple list features in comments. (Font because the > > default comment font changed somewhere in the past and I don't want comments > > with different fonts in a document. -- I simulate lists with "* Blabla" now.) > > We should likely decide what the optimal font size is for comment and not > allow users to change it. We default to 10pt, MS Word uses 8pt, and Google > Docs uses Arial 10pt. I don't understand the usability thinking behind this. Just as there is no single "optimal font size" for a document, there is the need from users to be able to change the size and font within a comment. I assume you are suggesting this because it would make the code simpler. I can't think of any other reason for suggesting it. I would prefer it if you could put the user's needs first, rather than the programmers' convenience. > > I think there should be a paragraph style for all comments in a document > > with a small set of paragraph features available and very limited direct > > formatting if any. Use cases like in comment 5 need more than one paragraph > > style for different notations with various paragraph features. > > The only thing i'd put into a comment paragraph style would be the font name > and allow users to change it, so its not repeated in each character style. > In comment 5's use case, I would suggest that a user can apply an existing > document-level character style to a comment, but it would be a limited set > of formatting options, and it wouldnt overwrite whatever default font size > that are assigned to comments. I assume you're not suggesting a single "comment paragraph style"? Or if you are, that it can be overridden on a case-by-case basis as the user needs. > > Before implementing a style there should be a consent of what features we > > want to be available in Writer comments and subsequently in other LibO > > components too. > > Yep we should do this. If we have a look at the formatting all comments > character dialog, i'd say we should keep, font name, font style, > underlining, strikethrough, overlining. I agree with that, yes. It makes it easier to have editorial discussions via comments. I think change tracking, for instance, is probably unnecessary and would be overkill. > (In reply to Luke Kendall from comment #16) > > Please note that it's extremely helpful to have font sizes supported, as > > comments can get very long, and reducing the font size is a good way to make > > more of them visible without having to click into them and scroll about, > > only able to see a small window onto it. > > That would be the wrong way to fix the issue of long comments. See bug 89232 > for the discussion on how to improve that issue. I just read that. Since a comment can grow very long indeed, all those changes would address the problem for about another 10% of comment length. After that, allowing the reduction of font size addresses maybe another 20%. (These numbers are, of course, my gut-feeling estimates: they're not backed by data.) Beyond that, the scrollbars of course become essential - unless you were to propose a separate document window could be popped up just to view the comment. Comments can grow arbitrarily large. There is finite screen space available no matter how you improves the comment box layout. Therefore, reducing the font size will remain a useful option. Please also consider that some people are viision-impaired: so for them, being able to increase the font size would be more than just helpful. > > You might also consider whether you could reuse the existing code for > > editing and display of text, from the full writer, rather than having to > > implement a separate text editor and text display algorithm. > > The current implementation gives similar text editing features that are > available in textboxes, as doing comments like text in full writer would be > overkill. My suggestion was to reduce the code size and reduce the chance of new sections of code that could then have there own bugs. It was not because the features are needed: e.g. footnotes and such. You might consider just limiting the UI for the comment editing so that the extra functionality wasn't available. As things stand, comments already have several other bugs in the operation of their existing text editor, such as wrong sized or placed scrollbars, wrong text selected or insertion point chosen when you click into them, etc. I think the bug in which font size changes to comments weren't being stored has been fixed, though. I'm only pointing this out to indicate that the existing comment display and editing code does not work anywhere near as well as the general, more powerful text editing and display functionality of Writer proper. Please consider getting some opinions from the UX people before you remove functionality which I find very important in my everyday use of LO. I am depending on these existing features. I think many other users would be, too.
(In reply to Heiko Tietze from comment #19) > Disagree on the "not allow to change" aspect. Consider accessibility, > additionally to the lengthy comments use case in c5. Please explain what accessibility you are referring to, as a user can easily zoom in/out for readability. Also remember that the author name and date/time of comments are unchangeable at 9pt. Comment 5 didnt mention about lengthy comments, it was about setting the importance of comments with different font sizes. But having users work around the problem of lengthy comments by changing the font size isnt a good solution.
(In reply to Yousuf Philips (jay) from comment #21) > Comment 5 didnt mention about lengthy comments, it was about setting the > importance of comments with different font sizes. But having users work > around the problem of lengthy comments by changing the font size isnt a good > solution. Since you refer to my comment 5, I would like to reply. You're right that the main purpose of the font size in my example is to set the importance of the comment. Nevertheless al lot of my comments are very long. But my aim is to see as much as possible without scrolling. But there is one important point, which wasn't mentioned so far: I often print my documents with comments in margin. For that reason it is important to see as much text of your comments as possible. If you really want to fix the font size, a comment style would no longer be an enhancement but a big disadvantage of LibreOffice.
(In reply to Yousuf Philips (jay) from comment #21) > (In reply to Heiko Tietze from comment #19) > > Disagree on the "not allow to change" aspect. Consider accessibility, > > additionally to the lengthy comments use case in c5. > > Please explain what accessibility you are referring to, as a user can easily > zoom in/out for readability. Also remember that the author name and > date/time of comments are unchangeable at 9pt. In along document, zooming in or out is a desperation measure, as it can take a long time for the zoom to occur. And when you do that, you then typically won't be able to see all the text that the comment refers to. So you would be unable to read both the document text and the comment text remarking on it at the same time (without a lot of scrolling). Then you would have to zoom back out and navigate your way to the next comment. > Comment 5 didnt mention about lengthy comments, it was about setting the > importance of comments with different font sizes. But having users work > around the problem of lengthy comments by changing the font size isnt a good > solution. We will have to agree to differ on this point. I think it's a good mechanism that's suitable for a moderate range of cases. My personal opinion is that the suggestion you've made above isn't a good solution because it would waste huge amounts of my time, when used in long documents.
(In reply to Luke Kendall from comment #20) > I don't understand the usability thinking behind this. Just as there is no > single "optimal font size" for a document, there is the need from users to > be able to change the size and font within a comment. The purpose of comments is to discuss segments of a document without editing the segment being discussed, just like we are making comments in this bug report. We dont need to set font attributes to these comments, though some people do throw in text emphasis marks, to have such a discussion, so i wouldnt compare formatting of comments with the the styling of a document. > I assume you are suggesting this because it would make the code simpler. I > can't think of any other reason for suggesting it. I would prefer it if you > could put the user's needs first, rather than the programmers' convenience. No i'm saying this as i'm part of the design/UX team and also deal with interoperability. If you open documents created with large font size in other office suites, the set font size and sometimes the font name wont be displayed. > I assume you're not suggesting a single "comment paragraph style"? Or if you > are, that it can be overridden on a case-by-case basis as the user needs. Yes i'm suggesting a single comment paragraph style to define the base font name and size, where individual comments can have character styles to change things as needed. > I just read that. Since a comment can grow very long indeed, all those > changes would address the problem for about another 10% of comment length. > After that, allowing the reduction of font size addresses maybe another 20%. > (These numbers are, of course, my gut-feeling estimates: they're not backed > by data.) Beyond that, the scrollbars of course become essential - unless > you were to propose a separate document window could be popped up just to > view the comment. Yes the mechanism to deal with many comments, large comments and nested comments need to be addressed, as also discussed in bug 89232. If you would like to discuss that issue further, please comment there. > Comments can grow arbitrarily large. There is finite screen space available > no matter how you improves the comment box layout. Therefore, reducing the > font size will remain a useful option. Large comments could easily be shrunk when they are not needed or in not focus, rather than reducing their size. > Please also consider that some people are viision-impaired: so for them, > being able to increase the font size would be more than just helpful. Visually impaired users would resize the entire document view larger with the zoom functions and not increase the size of the document text and comments, or else they would have difficulties collaborating with non-visually impaired users on the same document. > My suggestion was to reduce the code size and reduce the chance of new > sections of code that could then have there own bugs. It was not because > the features are needed: e.g. footnotes and such. You might consider just > limiting the UI for the comment editing so that the extra functionality > wasn't available. Yes the simplest thing would be to disable the functionality from working when editing comments, in the character dialog and from being displayed if already set. > As things stand, comments already have several other bugs in the operation > of their existing text editor, such as wrong sized or placed scrollbars, > wrong text selected or insertion point chosen when you click into them, etc. > I think the bug in which font size changes to comments weren't being stored > has been fixed, though. I'm only pointing this out to indicate that the > existing comment display and editing code does not work anywhere near as > well as the general, more powerful text editing and display functionality of > Writer proper. Yes quite aware of the current bugs and fixes that have gone into LO related to comments over the last few years and hope that fixing this one bug will resolve many of the bugs from occurring. > Please consider getting some opinions from the UX people before you remove > functionality which I find very important in my everyday use of LO. I am > depending on these existing features. I think many other users would be, > too. As stated above, I am part of the design and UX teams and we also have Heiko in this discussion who is also part of the team and lets bring Cor and Stuart in as well for their takes on the issue. And of course Regina for her valuable insights. :D
(In reply to Yousuf Philips (jay) from comment #24) > (In reply to Luke Kendall from comment #20) > > I don't understand the usability thinking behind this. > ... We dont need to set font attributes to these comments, ... There is a request to reduce the font size (for more or less good reasons but that's a different topic) and to enlarge it (of course, zoom is an alternative). And actually I don't get the point of this restriction as it adds trouble. To me the comment style is just another predefined paragraph style with a meaningful background color, font size/name/style, margins... everything is there. And I don't see the point why users shouldn't be able to customize the comments. Opening the document in another tool applies the default, sure. But I guess on this occasion we can be the driver and this awesome feature would get introduced soon. (Great thread, btw.)
In ODF, a comment is an <office:annotation> element. It is essentially the same as the Draw object "Legend" (.uno:DrawCaption from .uno:TextToolbox) from point of its attributes. It only has some additional attributes to be able to bind it to a table cell. And that gives some implementation difficulties. There exist currently no implementation, that users can apply a style to a paragraph or character or list inside the text of a Draw object. In addition there exists no implementation in Writer to use styles for Draw objects. All is done with hard formatting aka automatic styles. Having styles on comments can not be seen isolated, but only in the more general request to allow user styles on the text inside of Draw objects. And for the problem to have a better way for reply to a comment: There exists no attribute in ODF to link an <office:annotation> to another <office:annotation>. Therefore a "reply to" cannot be expressed as link. In theory and from a formal point of view, it would be possible to insert an <office:annotation> into a <text:p> element of another <office:annotation>. But that is far beyond the current implementation of text in Draw objects.
Regina, is it possible to apply a style as attribute to the elements <text:list> and <text:p> in a comment? They are child elements of <office:annotation> as you said and referring to ODF spec [1]. Other p tags contains style atteibutes too, why should it not possible here? [1] http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1416194_253892949
The paragraphs in a comment have already styles in LibreOffice. If they had no own style, then they would inherit the properties from the default paragraph style. But you cannot apply a user style from the Style and Formatting dialog. If you e.g. set the paragraph to "justify" via symbol in the toolbar, then that is stored in a style. But it is an automatic style. And that is the same for all Draw objects. It is not a limitation of the file format, but only LibreOffice cannot handle user styles. Wort or TextMaker show them correctly in the comment. But because the Draw objects have the same problem and they are nearly identical to comments, the aim should not be to find a single solution for comments, but establish a solution for Draw objects in the same task. A list inside a comment is not possible in LibreOffice. That is a missing feature too. Word or TextMaker show a list in a comment in an odt-document, LibreOffice not.
I'm inclined to agree. From a user's perspective, there appears to be something determining the "style" of comments (or else they wouldn't change based on the content of the document). Not being able to control that "style" (or whatever it is in the code) feels like a missing feature. Alternatively, just make all comments Helvetica 10 and leave it at that. But having only *some* formatting that is determined by *something*, including a one-time-only global change, is a maddening UX. Again, I don't know the code. Just speaking as a user.
Created attachment 132873 [details] Comment with a user style and bullet list File with user style "blue" on the first paragraph of the comment. The paragraph is followed by a bullet list. If you will see it in Word, you need to enable the "Reviewing Pane" in the "Review" tab. TextMaker shows the comment besides the page, same as LibreOffice.
(In reply to Regina Henschel from comment #28) ... > It is not a limitation of the file format, but only LibreOffice cannot > handle user styles. Wort or TextMaker show them correctly in the comment. > > But because the Draw objects have the same problem and they are nearly > identical to comments, the aim should not be to find a single solution for > comments, but establish a solution for Draw objects in the same task. Allright, so it is not a problem of the ODF spec but of LibO. That's "good" because we can handle that easier here. :) I can't imagine what these Draw objects are. Can you explain and should we adapt the bug summary?
@Thomas Lendo: Draw objects are those, which you get from the drawing toolbar. The symbol to show the drawing toolbar is right most symbol in the standard toolbar in Writer. Comments are similar to what is called "Callouts" there.
(In reply to Orion from comment #29) > I'm inclined to agree. From a user's perspective, there appears to be > something determining the "style" of comments (or else they wouldn't change > based on the content of the document). Not being able to control that > "style" (or whatever it is in the code) feels like a missing feature. > > Alternatively, just make all comments Helvetica 10 and leave it at that. But > having only *some* formatting that is determined by *something*, including a > one-time-only global change, is a maddening UX. > > Again, I don't know the code. Just speaking as a user. I'd just like to reiterate that in this user's opinion, a single fixed font size for comments would be a maddening UX feature. I would have to stop using LO for collaboration with my editor if that limitation was introduced. I could still use LO for other purposes, however. For me, the main feature I need in the presentation of comments is to be able to read the text in them; the more of the text I can read without scrolling (or zooming the whole document) the better.
*** Bug 55682 has been marked as a duplicate of this bug. ***
Most new user face that how to use remote desktop connection, i want to tell them about windows 10 they just click on https://windowsclassroom.com/enable-remote-desktop-windows-10-use and get all solution noo has any problem to face...
The information you share is very good so I am very curious about your next posts. https://wordle-2.com https://iogamesio.onl/
<a href="https://nailholiday.com/">nail designer charms</a> can be used for many different purposes including dressing up a kawaii manicure, making french mani more interesting and adding a touch of uniqueness to an otherwise simple manicure. There are thousands of designs available so one need not worry about running out of possibilities for their manicure any time soon! The only thing one needs to know is that these decorations should not be applied by themselves but rather on top of a base coat or even another color."
*** Bug 153805 has been marked as a duplicate of this bug. ***
Here is my attempt to make paragraph styles working inside comments: https://gerrit.libreoffice.org/c/core/+/152643 But note that comments use different text editing engine than normal text in Writer, so not all features of paragraph styles could be supported (e.g. paragraph background won't work).
(In reply to Maxim Monastirsky from comment #39) > Here is my attempt to make paragraph styles working inside comments: > > https://gerrit.libreoffice.org/c/core/+/152643 Hi Maxim, this is looking great. I applied your patch and tested it today and all I tried worked as expected.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c89d6d690ba4b48c235752a6193aa77d9ecb7384 tdf#103064 editeng: invalidate spelling results on style change It will be available in 24.2.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.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6e2c8f3f56ab52dfaa9bdce37423bac44cc64061 tdf#103064 sw: add a comment style It will be available in 24.2.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.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9474ff4cc0abbd16f91ea582050c2332bdad88a3 tdf#103064 editeng: fix handling of char highlighting It will be available in 24.2.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.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e229e13f9d5f1322986775399276f5503ebb83f7 tdf#103064 sw: improved notifications on style modification It will be available in 24.2.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.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d934aeace6e7049db3959421538ae382cb97b1d1 tdf#103064 sw,editeng: make para styles work inside comments It will be available in 24.2.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.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6c4edf7f86912084371e15be7321e9c4764a9ca6 tdf#103064 sw,editeng: enable UNO API and ODF import/export It will be available in 24.2.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.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6cb6f76095d2df07102ffd3da7accf7d075df90b tdf#103064 sw: use the comment style by default instead of DF It will be available in 24.2.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.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4923ddf33292cafecb5e216a5bdaac5bbe5da869 tdf#103064 sw: enable the UI commands It will be available in 24.2.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.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c66afb209de6132deac8fee9425a351391edc89e tdf#103064 Improve comment style usage detection It will be available in 24.2.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.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/4d5508e27bdccb7d1465686773bb57a14310ed14 tdf#103064 Don't overwrite all formatting with DF on lang change It will be available in 24.2.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.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/5ca721c182251e94922a7d11c6756f8ba789a574 tdf#103064 Refresh spellcheck marks on default lang change It will be available in 24.2.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.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6cc71f3eef4e5108e44ab6c1943def1d3a0f707a tdf#103064 Fix reset to parent style handling It will be available in 24.2.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.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/759d414748bda99f29b04806f72d479e320c2f9f tdf#103064 Simplify the code a bit It will be available in 24.2.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.
The basic implementation is merged to master, which should be enough to close this bug. Remaining issues can be handled in new bug reports.
Great work! Thank you, Maxim! VERIFIED with Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e25e27c85ed970cdb97c468bdac86c80964f4231 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded Should be added to release notes I think: https://wiki.documentfoundation.org/ReleaseNotes/24.2
(In reply to Maxim Monastirsky from comment #39) > But note that comments use different text editing engine than normal text in > Writer, so not all features of paragraph styles could be supported (e.g. > paragraph background won't work). Is direction working properly?
I really like your post, because all the information posted in this article is very Impressive. Suppose you are looking for hot and sexy call girls in Chennai. You may visit my excellent profile by clicking here. https://www.codella.biz/chennai-escorts/
Thanks for posting this post it is really more impressive and valuable. Keep posting like this article. Let me introduce myself Ashika Soni from Bangalore, If you are looking for any companion then I am available for you. Visit my to know more: https://www.ashikasoni.com
Added to release notes: https://wiki.documentfoundation.org/index.php?title=ReleaseNotes%2F24.2&type=revision&diff=691206&oldid=688350 Please don't hesitate to add information or modify it.
(In reply to Eyal Rozenberg from comment #56) > > Is direction working properly? Ping about this. Also - what's the "superordinate object" of comments, for the "superordinate object direction"?
(In reply to Eyal Rozenberg from comment #60) So, direction seems to work mostly fine. Except - it's not clear what the "superordinate object" for direction is, nor what it should be. Should it be the page direction? That would mean different directions on different pages; do we want this? Alternatively, it must be the "document direction" - except that we don't have that (at least not in the UI); we only have the direction of the default page style. Maxim?
Also, what does "Format all comments" do now? Should it not have been removed by the patch? Or redirected to editing the Comment paragraph style? Since this is verified I'll open a separate bug.
(In reply to Eyal Rozenberg from comment #61) > Except - it's not clear what the "superordinate object" for direction is, To the best of my knowledge, "superordinate object" direction isn't implemented for comments, and for now it just hardcoded as LTR. This isn't specific to styles, as the same issue exist also for DF (via Format > Paragraph...). > nor what it should be. Should it be the page direction? I believe so. I'm not an ODF expert, but the "superordinate object" direction is exported as style:writing-mode="page", and according to Appendix E.1 of the spec - "This value specifies that the paragraph direction is inherited from the layout direction of the closest layout object (section, table or text-box) in which the paragraph is contained, and which has a layout direction other than page. If the paragraph is not contained in any of these layout objects, the paragraph direction is inherited from the page on which the paragraph appears." > That would mean > different directions on different pages; do we want this? This isn't different from the document body text: If a paragraph shifts to another page with a different direction, it will also change its direction.
(In reply to Maxim Monastirsky from comment #63) > This isn't > specific to styles, as the same issue exist also for DF (via Format > > Paragraph...). I'm not sure I understand what you mean, since if you DF a paragraph to take the superorindate object direction - it uses the page (sequence) style. > > nor what it should be. Should it be the page direction? > I believe so. I'm not an ODF expert, but the "superordinate object" > direction is exported as style:writing-mode="page", and according to > Appendix E.1 of the spec - "This value specifies that the paragraph > direction is inherited from the layout direction of the closest layout > object (section, table or text-box) in which the paragraph is contained, and > which has a layout direction other than page. If the paragraph is not > contained in any of these layout objects, the paragraph direction is > inherited from the page on which the paragraph appears." > > > That would mean > > different directions on different pages; do we want this? > This isn't different from the document body text: If a paragraph shifts to > another page with a different direction, it will also change its direction. So, shall we file a separate bug to request this, or should we reopen this one?
(In reply to Eyal Rozenberg from comment #64) > I'm not sure I understand what you mean, since if you DF a paragraph to take > the superorindate object direction - it uses the page (sequence) style. I mean a DF of a paragraph inside a comment, i.e. open Format > Paragraph... when a comment is focused, so you format the comment itself, not the document text. > or should we reopen this one? Let's not.
Great things you’ve always shared with us. Just keep writing this kind of posts.The time which was wasted in traveling for tuition now it can be used for studies.Thanks (Minecraft PE Apk)(https://mcpepro.com/)
I think this is an informative post and it is very useful and knowledgeable. therefore, I would like to thank you for the efforts you have made in writing this article. nhs band 7 https://paidhours.co.uk/nhs-band-7-pay/
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/aa8d68f9764eb7714871de7c56b5a0ca7c2ead8b tdf#103064 editeng: fix handling of char highlighting It will be available in 7.6.3. 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.
Thanks a lot, that makes the use case clear. +1 also from me now. https://www.yogitafun.com/
*** Bug 160662 has been marked as a duplicate of this bug. ***