[Libreoffice-bugs] [Bug 135871] Highlighting no fill is not the same as no fill; there is still direct formatting present according to paragraph style

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=135871

--- Comment #11 from Luke Kendall <luke.kendall at gmail.com> ---
(In reply to Mike Kaganski from comment #9)
> (In reply to Telesto from comment #8)
> 
> "I'm not asking for hundreds (or thousands of tools). I'm only taking about
> this function. And that function. And also that one. And this. And I don't
> realize that that is just my list of favorites, and others have different
> lists; and also many have consistency in mind; so having *some* set of tools
> to reset special DF, the question arises to make other DF to have those
> counterparts, too. And I have that delusion that I can create a workflow
> "using styles", where DF fits."
> 
> No, it's true that "You need to be very very disciplined not to use DF
> somewhere". And no, it's not that "using Ctrl+B is faster", it's "I need t
> learn how to set up my key combination to use styles instead of DF". There's
> no efficient workflow that includes both DF and styles, not because there
> are no "reset specific DF" tool, but because they are just ideologically
> mutually exclusive. And too often I see people here have ideas like "I see
> this small problem, and I have this great idea, and I am sure it's nice to
> have, and I don't want to learn to see the whole picture, to see that this
> local solution would maybe allow some specific thing, but in the expense of
> much greater problems, not only because of much greater complexity in the
> software and maintenance, but also promoting not what I think it will (using
> styles), but a different and very problematic - using DF".

I agree.

I may also have had a brilliant idea.

Let me first recap to check my understanding:

   Once you have used DF, nothing will get the text back to non-DF except
Ctrl-M.

The DF commands that appear to toggle, don't - I think that's the major source
of the problems caused by the design of DF in Writer.  When you have used DF to
change back to the default appearance, the text is still DF. That's the heart
of the problem.

I think a more natural semantics for Writer would be that if a piece of text's
properties equals that of the text adjacent to it on the left or right, its
style should be automatically changed to that style rather than leaving it
marked as DF.

I think that would solve many of the usability problems and user confusion
around DF, at a minimal run-time cost of some extra code run after DF is
applied, to try to simplify (minimise) the styles.  In other words, to actively
work to clear a DF indication if the text's properties makes it LOOK identical
to the text it's adjacent to either on the left or the right.

But that's not my possibly-brilliant idea, which I'll sketch out now.

I was thinking of one added new function for the user - let's call it Simplify
- that's similar to Ctrl-M in ONE respect: it removes DF in any selected text.  
But what this new Simplify function does is that it makes no change to the
text's appearance, instead finding styles that exactly match the text's
appearance.

Method:
It iterates over the characters in the text in a single pass.
It gathers each character into a run of text of the same text properties,
trying to make the longest run of text it can.
For that run of text, it then looks through the defined styles, for an exact
match.
If it finds an exact match, it clears DF and sets the run of text to use that
style (or combo of character and paragraph styles).
If it cannot find an exact match, it creates a style (Simplify<N> and
increments N), and assigns that to the text, and clears DF.
It then continues, building the next run of text.

In this way, all DF is removed from the selected text, the text has no visual
change, and a minimal set of styles are used or created, putting the document
in good shape for further work.

What do you think?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200902/74ce5156/attachment.htm>