[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 #42 from Telesto <telesto at surfxs.nl> ---
Created attachment 165712
  --> https://bugs.documentfoundation.org/attachment.cgi?id=165712&action=edit
Example file

(In reply to Mike Kaganski from comment #41)
> Your idea "let's "B" behave conditionally depending on where it is used"
> will make behaviour of the result very confusing for Benjamin.
> 
> He has some text, where some parts are bold - because of DF on char level;
> some parts bold from DF on paragraph level, some parts bold from styles -
> both character and paragraph.

-> Some parts bold from DF on paragraph level; Is this possible? PS affect the
whole paragraph?
> 
> He uses the same "B" tool to make it not bold. Currently, this applies "no
> bold" explicit attribute in all these cases. You suggest to make the result
> conditional, making those places that were bold because of character-level
> DF to simply loose "bold" attribute; so your suggestion would make new
> non-bold parts being different - some having explicit "non-bold" attribute
> (where that is above e.g. paragraph-level formatting), some no bold
> attribute at all.

I dislike using 'conditional' without explicit context. It's rather confusing


1) The paragraph formatting pretty conditional. Copy/paste text with default PS
to a different paragraph with Preformatted Text. Formatting will change :-)

2) DF isn't even conditional all the time in my model. Say, select a line of
text & press bold. Now change page style and apply bold. The 'bold' of the DF
isn't gone. 

3) Open a document, select a part of the text. Press CTRL+I. Now go to sidebar
styles - cs -> Apply Emphasis. The direct formatting is gone and replaced with
CS. 

4) Open the attached file. Select the first three lines and drag after sidewalk
(bold bottom). A part won't be highlighted (because of DF unbold present). This
Benjamin doesn't like that either. 

5) Open the attached document, Select the first 3 sentences. Sidebar -> Styles
-> CS style emphasis (strong emphasis disappears) because based on CS style
(not DF) [bit off topic, but you simple can't tell the difference on screen]

6) Open the attached file, Select "That didn't bode well." press bold toggle
button (unbold) and again (bold). They CS style is still set (see sidebar cs
styles), they layout still matches CS (but is ruined by DF).  

So I don't see the 'current' implementation not having the same deficit, as
'expected' of mine. The issue is already present. And as far I concern even
more obvious. Because using DF somewhere in the text and go on typing.. it the
whole text gets DF (example of Luke). 

So if i'm weighting the 'downsides' of the current implementation. Compared to
the downsides of my proposal, I assume a 'win' situation. Yes, there will be
formatting issues. But this is the case already; so nothing new on the horizon,
IMHO. Layers of formatting is per definition hard to follow :-). A reason for
me simply avoid CS styles. I'm able to follow the concept of PS + DF. Adding CS
to the mix, and i'm out (as I really don't know where the formatting is coming
from. Because it matters in which order the stuff gets applied. Italic DF gets
removed by CS Emphasis etc 

Again, based on what I can see. Quite a number of variables. They styles
hierarchy, order of applying formatting. Copy/paste etc. So might overlook the
obvious? So would love some STR's where this works worse (compared to current
case). Based on what I see I assume the current way of doing things is even
more prone to formatting surprises for Benjamin (as long as modified styles are
involved). Without deviating styles present, this not interesting at all.

The whole advantage of 'quick' changing formatting is pretty ruined by the DF
debacle, IMHO. And pretty unnatural. BOLD toggled off but still being on etc. 

But I must admit, I mostly discover the flaws/ thinking mistakes after the
fact.. When playing around etc

-- 
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/20200921/61d83ee3/attachment.htm>