I'm not a regular user of F&R (except the basic string of text).. 

However the font size on pag 22 appears to be 10,5 pt. So searching for 10 should't give results.. And you have to check Including styles (not clue why it's excluded by default)

Not all the fonts on "22" are in 10 pt, just a few selected pieces (whispered).

I didn't know waht the "Including styles" meant, but after reading https://help.libreoffice.org/6.4/en-US/text/shared/guide/find_attributes.html I thought it might do what I expected.  It doesn't, though.

With it turned on, I can't work out what it's finding. Certainly nothing that makes sense to me.

I expect it to at least find all Georgia text font in 10pt. It doesn't. It finds some Georgia 10.5, some Georgia 7pt, some Georgia 10pt, and doesn't find other Georgia 1pt (such as that on the page titled "22").

If you do a Find All with Include Styles turned on and then scroll around, it makes it obvious how weird the behaviour is.

Anyway, see what you think.

Generally the F&R needs much love.

I suppose that there could be two alternative ways to improve the situation. One would be to make attribute search find any attribute applied to the character, regardless on which level that formatting is applied.

Another would be to expand style search to allow searching for different kinds of styles (not only paragraph, but also character, list, ...), and then to explicitly mark attribute search as "search for direct formatting".

The first option might seem more intuitive at first; but I suppose that it goes in wrong direction - against the ideas around which LibreOffice is built.

The "proper" way to work with Writer is *using styles*. Style is some *named* set of formatting; and the details of formatting themselves are not as important as the fact that some parts of content bear that style. User might mark some text "quotation", another "heading", yet another "note" or "code snippet", etc. And it's that *semantical* meaning that is most important from the document structure point of view, that makes this electronic document easily maintainable, consistently formatted, etc.

Carefully using styles, user mostly doesn't need to search for formatting: whenever user decides that their quotations need not only be italicized, but also indented or have borders, user just finds the style name in the list, and modifies the style definition, thus making document-wide change, having all parts using the definition looking consistently without touching each part individually.

On the other hand, user might look for formatting mostly when that formatting is *not* part of carefully styled document - i.e., when the formatting is applied directly. E.g., user might want to look for bold text (that they used for, say, headings), and replace that with a different font name and size. F&R dialog is the only way to automatize the task for direct formatting case. But of course, you see how that may become dangerous, if your document also contains parts of bold text used for emphasizing something...

Simply allowing users to search for "bold applied not only directly, but also using character style" would most probably emphasize the *wrong* philosophy of working on documents: e.g., finding "bold" (from style) and applying "non-bold italic" (as direct formatting) using F&R would make the document a mess of direct formatting over styles ... something to be discouraged.

But not allowing to search for styles is also bad. My preferred solution thus would be to separate searching for character styles (by name, not by "bold"), and marking attribute search as "direct formatting only" for clarity.

Of course, instead of searching for styles in F&R (or in addition to that), an option could be useful to right-click a style in F11 panel, and "select all occurrences" from context menu (a topic unrelated to this bug though).

Thanks for all that Mike, but I do understand the appeal of styles.

I feel a few brief points might be worth making, since I understand you're in the "Strong Styles" camp.

1/
This particular bug argues against such a strict use of styles, as the bug make it impossible to find text styled exactly for the purpose you describe.  There is no way to find text marked with Whisper style, and that text only.

2/
Secondly, the "strong styles" position refuses to acknowledge that there are two kinds of users - one class who format their documents according to styles (whether they know it or not), such as for HTML.  But not just for HTML: there's a large class of use cases where style markup is essential/important for good text management, and many workflows based on that.

But a second class of user is more casual.  For them, they are NOT making semantic distinctions and do not want to.  The surface appearance is all that matters.  In my view, Writer takes a very hard stance that such a use case is not supported, and is in fact an erroneous use of Writer. (The user is an idiot and should do things the way we want them to.  Even when that will slow them down and make their work take longer.)

I can understand the appeal of such a hard line stance, but I think it's a big failure of UX, to reject a large class of users.

3/
From my experience with Writer, it seems there's a designed-in assumption that every new use of a style applied by direct formatting is a potentially new and unique piece of semantic markup.  I believe this is an extreme position to take, especially in longer documents.  The idea that a document could have thousands of different kinds of semantic markup is theoretically possible, but an extreme edge case.

I think the issue could be largely resolved by having one extra option that could be enabled: Minimise Style Creation. In this mode, if a style was exactly the same as one used before, then a (possibly auto-generated if it's new) style name is used.  All direct formatting would then be gone.

4/
Although I think from this you can see my viewpoint is quite different from yours, I really don't expect to be able to change your opinion.

5/
I did have a little look around for alternative word processors for Linux.  From my perspective, LO or maybe OOo are still by far the best options for most use cases, including mine.  Unfortunately the areas where Writer opposes me and makes my life VERY difficult are quite substantial too.

Perhaps half of those difficulties are simply caused by bugs, and some of them are fixed quickly (sadly, others stay for long, long years).

Even though it may sound like I'm ungrateful, I'm really not.  The only serious alternative would be to run Microsoft Office and that brings its own problems, possibly even larger.

You and all the other contributors in the open source community have done (and are doing) a magnificent job of producing such a powerful and well-managed piece of software. That it's not perfect, is something I can live with.

(In reply to Luke Kendall from comment #4)

Your PoV is not incompatible with mine; but your idea that just thinking that "not using styles is OK makes anything useful" (I will explain below) is incorrect.

You say something like "you (Mike Kaganski) tell that Writer is for using styles; but there are people who don't use styles, and your approach reject that large class of users". You are wrong.

What I say is that the two workflows are very different, and when users don't use styles, they don't need to search for styles. When users use styles, they do that differently. These both workflows *don't* require searching for "bold applied through style" - or you need to provide a specific use case where it's needed. Even if you provide that, we need to consider ways to keep Writer in a state where both ways are distinct, and do not result in *poorer* experience to *both* classes of users. E.g., a specific use case that you may provide could have an alternative solution, not mixing the two totally different kinds of "formatting". Only when there's an agreement that there exists a case that is important enough to consider "regressing" of workflow for some other group of users, should we consider doing that: not "I found something that I *guess* sometimes may be unexpected for an imagined user - but I don't know if that's actually a real case; let's change that for that imagined case". That's my point.

(In reply to Mike Kaganski from comment #5)

Stressing my previous comment's bottom line: we need to consider problems making some actual work difficult or impossible, and always consider adverse effects not only to one class of users.

For this specific case, *possibly* adding a checkbox (unchecked by default) like "search also attributes from styles" could be reasonable (but I still fail to see a use case where it's needed).

I didn't think you'd be able to see my POV.

Just a quick note, because I really don't have time to try to explain myself better.

Unless the Writer team has done some proper UX studies, it's all guesswork about use cases and how many users are affected by different aspects of the Writer design.

I'm not surprised you dismiss 40 years of experience as irrelevant and that you know better "Your POV [...] is incorrect"; "You are wrong").

I continue to find features in the UX side that are counter-intuitive and cause problems in my workflows, and when I talk to other users I also hear of similar problems.

It's probably one of the reasons why so many user problems are 'resolved' by the explanation that the user applied direct formatting, so of course feature X or Y didn't work.

Anyway, we're now having the argument I didn't want to have and which is way off topic, so I'll not say anything further on this subject.  A bug report is not the place for such a discussion.

Sigh.

(In reply to Luke Kendall from comment #7)
> "Your POV [...] is incorrect"

This is so ... you chose to cite incompletely, thus constructing something from parts of my phrases that you choose to make me look saying I didn't say. Luckily, my words are there, and anyone may see that I actually wrote: "Your PoV is not incompatible with mine". Again: there I said that our points of view are in fact compatible; and you citing that way just attempted to look it both the other way round, and rude. Nice of you.

> ; "You are wrong").

And reading *my* words, not your interesting quotations, one may see that I said that only some aspect is incorrect: saying that my approach is reject that large class of users who don't use styles.

Citing it in full, just for the record:

> Your PoV is not incompatible with mine; but your idea that just thinking
> that "not using styles is OK makes anything useful" (I will explain below)
> is incorrect.
> 
> You say something like "you (Mike Kaganski) tell that Writer is for using
> styles; but there are people who don't use styles, and your approach reject
> that large class of users". You are wrong.

Again: you are wrong when you tell that I suggest an approach that rejects people who do not use styles.

Then - you fail to see that I try to address your bug, not close it. I propose to think about alternative ways to solve it. But you are behaving like "I have so huge competence and experience!!!" (as if you know my background not having something comparable). "If you do not agree that *my* proposal how to fix it is the only one possible, then you are unable to see other's PoV" ... heh, just try to read how backward is that.

Nevertheless, no matter if OP wants to participate here or not, the issue deserves UX team attention.

I'm happy that you're trying to fix the bug; and I'm perfectly happy to do what I can to support you in that.

I genuinely thought you were saying "Although our views are compatible, you are wrong."  Because I felt you were saying that, I felt mildly annoyed.  I was not misquoting you to mislead or to put words in your mouth: my abbreviated summary was to express how I interpreted your words.

I'm happy that you did not mean them as I read them, and quoted (an excerpt to highlight the meaning I saw).

Perhaps I'm reading more into your statements than I should.

I do not assume you must follow my suggestions about how to fix this bug, or any other.

In general (and in this case too), I would assume that because you are an expert on Writer compared to me, that your idea how to fix it would be correct.

Maybe I'm wrong, but I think the part where you are proposing some ideas for fixing this bug are:

"Simply allowing users to search for "bold applied not only directly, but also using character style" would most probably emphasize the *wrong* philosophy of working on documents: e.g., finding "bold" (from style) and applying "non-bold italic" (as direct formatting) using F&R would make the document a mess of direct formatting over styles ... something to be discouraged."

I can't comment on that because I don't understand direct formatting and Writer's styles deeply enough to really grasp the problem you're explaining.

"But not allowing to search for styles is also bad. My preferred solution thus would be to separate searching for character styles (by name, not by "bold"), and marking attribute search as "direct formatting only" for clarity."

I think I understand this suggestion; and it seems a good solution to me.

(In reply to Dieter from comment #10)
> I must admit, I haven't read the whole discussion in deatil, but in sum it
> seems more like an enhancement request than a bug. So let's involve design
> team for further input and decision
> cc: Design-Team

Me neither, quite a lot off-topic. 

Searching with restriction to attributes should work as designed, meaning Format > Font = <foo> should return the results. It does for me (dummy text, one word with C059 font, format = font name and font size). So not an UX topic.

(In reply to Mike Kaganski from comment #3)
> Another would be to expand style search to allow searching for different
> kinds of styles (not only paragraph, but also character, list, ...), and
> then to explicitly mark attribute search as "search for direct formatting".

Search for character styles is a similar RFE as in bug 133300 about page style. Proposal was to have a new tab that not only allows to search for paragraph styles but also other styles.

(In reply to Heiko Tietze from comment #11)
> Search for character styles is a similar RFE as in bug 133300 about page
> style. Proposal was to have a new tab that not only allows to search for
> paragraph styles but also other styles.

I propose to reduce the bug report to that enhancement request. And since searching for page style has also been accepted, searching for character styles should be accepted, too.

Luke, Heiko, what do you think?

(In reply to Dieter from comment #12)
> (In reply to Heiko Tietze from comment #11)
> > Search for character styles is a similar RFE as in bug 133300 about page
> > style. Proposal was to have a new tab that not only allows to search for
> > paragraph styles but also other styles.
> 
> I propose to reduce the bug report to that enhancement request. And since
> searching for page style has also been accepted, searching for character
> styles should be accepted, too.
> 
> Luke, Heiko, what do you think?

Sounds like a good idea, to me.

It sounds good to me too.
The only potential problem I see is a potential UX one: might direct formatting make a search fail, when a user who doesn't understand DF would expect it to succeed?
Will the search have a way to find a match based on what the user sees, rather than on some part of Writer's internal representation? If so, that potential issue might be minimised.

HTH,

luke

Question about operation of "Find-Replace" with Format.

Using attachment 161331 [details], here results of “Find All” in Find and Replace dialog, using “Format” with following settings (and always with “including styles”) 

1.  10 pt             Result:  highlights all 10 pt, including on last page.
2.  Georgia           Result:  highlights all Georgia, with a few exceptions.
3.  Georgia, 10 pt    Result:  highlights (almost all) 10 pt Georgia text with some exceptions
4.  Georgia, 10.5 pt  Result:  highlights all 10.5 Georgia Text Body text, including some on the last page that has a 10pt applied character style), with some exceptions.

About exceptions.  All are Text Body PS, but with some kind of direct character formatting or applied character style. Try especially variation 3 and 4, to see how these exceptions are selected or not.

E1. "Original release:	Jul 2016."
E2. "Release version: 8.May 2020. (Fixed 3 ‘smartquotes’, left indent 1st para.s)"
E3. "the Afterword"
E4. The paragraph that starts:   “I am not one to read dark…”
E5. The 10pt text on last page with applied character style.

Roughly – it appears that “Format” search (including Styles) gets disturbed with some certain kinds of direct character formatting (see difference between E1 and E2) or applied character styles.  

Tested with:
Version: 7.2.0.0.alpha0+ (x64)
Build ID: 4041c68ea59181f1c4774c356809066d2051db41
CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Vulkan; VCL: win

Without intending or expressing any opinions about the enhancement request here, I would like to know if a separate bug report should be filed about this behavior (because it is not about the enhancement request) or is this “intended design”?

Character styling is very nice if you want to later export to a DTP program that imports them correctly or to change the styling of all the text with said styling, or when you want quotes inside the regular paragraph or different small caps styles...

But I'm having the same issue. I have started using character styles recently, but if I want to reformat the document after pasting everything as plain text just to make sure there is no hidden formatting ruining the document, there is no such a thing as the equivalent to search for paragraph style.

Also, if you want to change the character style of a given word, there are only two ways to do it right now:
· CTRL+F plus CTRL+V manually for each word if using character styles
· Find & replace all with formatting without character styles.

Another use for this search function is when you have a document with several languages and want to include the translations as notes after formatting everything. You cannot do that now because those languages will turn invisible once the character style is applied.

For me, the ideal would be, in order of preference:
· An option to check for character style below the check for paragraph style & format search also including character style formatting.
· A buttom like the ones for format & attribute for character styling.
· A check in attributes to include character style formatting. This beeing the least intuitive.

(In reply to Dieter from comment #12)
> I propose to reduce the bug report to that enhancement request. And since
> searching for page style has also been accepted, searching for character
> styles should be accepted, too.
> 
> Luke, Heiko, what do you think?

Heiko, a kind reminder of my question.

(In reply to Dieter from comment #12)
> (In reply to Heiko Tietze from comment #11)
> > Search for character styles is a similar RFE...
> 
> I propose to reduce the bug report to that enhancement request. And since
> searching for page style has also been accepted, searching for character
> styles should be accepted, too.

Sounds reasonable to me.

(In reply to Heiko Tietze from comment #18)
> Sounds reasonable to me.

Thanks for quick reply. I've updated bug summary.

As this has clearly morphed into a duplicate of bug 78582, let's mark as such.

*** This bug has been marked as a duplicate of bug 78582 ***

(In reply to Stéphane Guillou (stragu) from comment #20)
> As this has clearly morphed into a duplicate of bug 78582, let's mark as
> such.
> 
> *** This bug has been marked as a duplicate of bug 78582 ***

I read through bug 78582, but couldn't see that it covers the problem of not finding text when it visibly matches the search string but some direct formatting can make it fail.

Are you sure that addressing bug 78582 will ensure such searches work reliably?