Bug 124748 - Modification paragraph border always adds a new border in specific situation, with borders merged over more paragraphs
Summary: Modification paragraph border always adds a new border in specific situation,...
Status: RESOLVED NOTABUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL: http://www.openoffice.org/specs/write...
Whiteboard:
Keywords:
Depends on:
Blocks: Paragraph-Borders
  Show dependency treegraph
 
Reported: 2019-04-15 09:04 UTC by Karsten
Modified: 2019-05-10 08:42 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Example document (11.13 KB, application/vnd.oasis.opendocument.text)
2019-04-15 09:05 UTC, Karsten
Details
Merge with next paragraph unchecked for selection (32.41 KB, image/png)
2019-04-23 13:03 UTC, V Stuart Foote
Details
Merge with next paragraph checked for selection (27.82 KB, image/png)
2019-04-23 13:15 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Karsten 2019-04-15 09:04:43 UTC
Description:
I just want to use an edit older documents.
But when i try to edit an line it will cause in random results.

This is after the update to the last stable version.

Steps to Reproduce:
1. Open the attached document
2. Try to modificate the line


Actual Results:
Additional lines will appear

Expected Results:
Only the line should be edited that is marked.


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 Karsten 2019-04-15 09:05:24 UTC
Created attachment 150760 [details]
Example document
Comment 2 Karsten 2019-04-15 09:06:24 UTC
Version: 6.1.5.2
Build-ID: 90f8dcf33c87b3705e78202e3df5142b201bd805
CPU-Threads: 4; BS: Linux 3.16; UI-Render: Standard; VCL: kde4; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: CL
Comment 3 Dieter 2019-04-15 09:22:22 UTC
The line is a paragraph border. I confirm the strange behaviour with

Version: 6.3.0.0.alpha0+ (x64)
Build ID: 421e6fc3cd2e6fe37afbef341e2d0ad7b8edde37
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2019-04-07_01:12:58
Locale: en-US (de_DE); UI-Language: en-US
Calc: threaded

and also in

Version: 5.4.7.2 (x64)
Build-ID: c838ef25c16710f8838b1faec480ebba495259d0
CPU-Threads: 4; BS: Windows 6.19; UI-Render: GL; 
Gebietsschema: de-DE (de_DE); Calc: CL

Step to repoduce:
1. Open document from comment 1
2. Put cursor in ine with "more text"
3. Format => Paragraph => Borders
4. Try to change style of the border above text

Result: A new border is created below the text
Comment 4 V Stuart Foote 2019-04-15 14:02:53 UTC
P15, P12, P11 all have border-top set to same border and color. They also have the "Merge with next paragraph" value set--meaning the first "border-top" will show. Subsequent do not. Uncheck that value to allow each paragraph to show its top border as set.

Paragraph dialog -> Borders in the Properties segment.
Comment 5 Dieter 2019-04-15 15:15:24 UTC
(In reply to V Stuart Foote from comment #4)
> P15, P12, P11 all have border-top set to same border and color. They also
> have the "Merge with next paragraph" value set--meaning the first
> "border-top" will show. Subsequent do not.

I understand, but I don't understand, why a new border appears, if you try to change the top border. So for me it looks like, that in this case "keep with next paragraph" rule is ignored, although this option is enabled.

So for me it would be at least an enhancement to improve the relationship between paragraph border and "keep with next paragraph" option. I change the status back to UNCONFIRMED. Perhaps we can collect some other opinions.
Comment 6 V Stuart Foote 2019-04-15 16:53:07 UTC
(In reply to Dieter Praas from comment #5)
> (In reply to V Stuart Foote from comment #4)
> > P15, P12, P11 all have border-top set to same border and color. They also
> > have the "Merge with next paragraph" value set--meaning the first
> > "border-top" will show. Subsequent do not.
> 
> I understand, but I don't understand, why a new border appears, if you try
> to change the top border. So for me it looks like, that in this case "keep
> with next paragraph" rule is ignored, although this option is enabled.
> 
> So for me it would be at least an enhancement to improve the relationship
> between paragraph border and "keep with next paragraph" option. I change the
> status back to UNCONFIRMED. Perhaps we can collect some other opinions.

It is not a new border. Rather IIUC the border "merge" will only occur if the direct formatting, or style, of the Paragraph border's match. Change the border of the first and the second will show--but the third will not as it matches the second.
Comment 7 Dieter 2019-04-15 17:20:55 UTC
(In reply to V Stuart Foote from comment #6)
> It is not a new border. Rather IIUC the border "merge" will only occur if
> the direct formatting, or style, of the Paragraph border's match. Change the
> border of the first and the second will show--but the third will not as it
> matches the second.

But if you change the border style you are in conflict with "keep with next paragraph" rule. I'm confinced, that the actual result is not the result "normal" users would expect.
Comment 8 V Stuart Foote 2019-04-15 20:22:15 UTC
This affects rendering of borders Top/Bottom/Left/Right, but also the Shadow constructed around the "merged" paragraphs.

The OOo era design document for this feature (see also aoo#17758) is here:

http://www.openoffice.org/specs/writer/compatibility/merge-borders-and-shadow.sxw

Seems it behaves as implemented.

=-ref-=

https://opengrok.libreoffice.org/xref/core/cui/source/tabpages/border.cxx?&r=4a6dc219#503
Comment 9 Heiko Tietze 2019-04-17 11:20:34 UTC
(In reply to V Stuart Foote from comment #8)
> Seems it behaves as implemented.

So close as WFM?
Comment 10 Dieter 2019-04-17 11:52:16 UTC
LO help: Merge with next paragraph
Merges the border style and the shadow style of the current paragraph with the next paragraph. These styles are only merged if the indent, border, and shadow styles of the next paragraph are the same as the current paragraph. This option is also available for Paragraph Styles.
(https://help.libreoffice.org/6.3/en-US/text/shared/01/05030500.html?&DbPAR=WRITER&System=WIN)

I thin it is not intuitive, if "Merge with next paragraph" is enabled, but the different paragraphes are not merged because of different indent, border, ...
Comment 11 Dieter 2019-04-17 11:56:13 UTC
Actually "Merge with next paragraph" is enabled by default. I think that problems like in the initial bug report can be reduced, if this option is disabled by default. I suppose, that this could be done very easily.
Comment 12 V Stuart Foote 2019-04-23 13:03:12 UTC
Created attachment 150948 [details]
Merge with next paragraph unchecked for selection
Comment 13 V Stuart Foote 2019-04-23 13:15:06 UTC
Created attachment 150950 [details]
Merge with next paragraph checked for selection

Attached are clips of impact of the "Merged with next paragraph" checkbox on the Format -> Paragraph -> Borders panel, and applying a paragraph shadow.

Note that the layout spacing and padding is cumulative when not merged--so page layout would jump when the border and shadow are enabled compared to disabled. So the distinction should be noted in documentation.

But other than that, I have no problem with changing the default to not enable the border/shadow merge. Despite it having been the default since feature was implemented for OOo. It probably should be noted in relase notes for 6.3 if changed.
Comment 14 Cor Nouws 2019-04-24 12:08:34 UTC
(In reply to Dieter Praas from comment #11)
> Actually "Merge with next paragraph" is enabled by default. I think that
> problems like in the initial bug report can be reduced, if this option is
> disabled by default. I suppose, that this could be done very easily.
By changing the default, I expect that many people will be annoyed by the behavior - see the example from Stuart.
The sample document from Kasten provides a rare situation, full of direct formatting oddities, for which I would not change the current behavior.
Comment 15 Karsten 2019-04-24 21:09:24 UTC
(In reply to Cor Nouws from comment #14)
> (In reply to Dieter Praas from comment #11)
> The sample document from Kasten provides a rare situation, full of direct
> formatting oddities, for which I would not change the current behavior.

Please explain the formatting oddities.
There is only one side set as a line.

The problem does not occur when you start a new document.
So i would say that someone does not check any backward-compatibility.

And i would say that it is normal that you recycle older documents or add some information to it.
Nearly nobody starts always from the beginning ...
Comment 16 V Stuart Foote 2019-04-24 22:00:22 UTC
The merge with next paragraph requires that to make the edits OP asked for, e.g. make the line thin to 0.1pt" requires that the subsequent paragraphs of the same direct formatting be selected when modifying the paragraph format of the top border set as a signature line.  

Clearly a RTM, and if we are not changing the default to merge--setting NAB.
Comment 17 Karsten 2019-04-25 12:10:23 UTC
Thanks.
But an design for intuitive handling is much better then an permanent RTFM.
Comment 18 Cor Nouws 2019-04-25 13:18:15 UTC
(In reply to Karsten from comment #17)
> Thanks.
> But an design for intuitive handling is much better then an permanent RTFM.
Clear proposals without drawbacks are welcome. For this particular example, I didn't see it. It's not fair towards all people working on LibreOffice to say "an permanent RTFM". But I hope I misunderstand you here :)
( Wrt document: lesson one with formatting oddities is: look at direct formatting. Ctrl+A, Ctrl+M  )
Comment 19 Karsten 2019-04-26 10:27:17 UTC
I know you will hate my answer, but just have a look at the old Word / Excel 97. :-)
I never did have an problem to set my frames there.
The way was intuitive clear without the need of RTFM.
(You see how long i am working with Star-Office, Open-Office, Libre-Office ;-)

The actual way is to complicate.

When you click on a line in the menu tab it has 3 different states - why?
Just make your choice of line width and type and then click on the lines you want to have active with this settings. This would be simple perfect.
If something is wrong then you can choose to clear all with the preset buttons that are already existant.

You can't find out which line width each line has - that's bad too.
A big problem if a line is destroyed by editing old documents.

When you want to have different line width in one table it is really difficult to get the result you want to have.

Another problem is that the line width is not rendered in a good way on the screen.
Comment 20 Cor Nouws 2019-04-26 11:26:17 UTC
(In reply to Karsten from comment #19)
> I know you will hate my answer,
Thanks ;)

> but just have a look at the old Word / Excel 97. :-)
Don't have them at hand and it's too long ago for me to remember.

> I never did have an problem to set my frames there.
> The way was intuitive clear without the need of RTFM.
I don't read the manual. but.. agreed the UI has its challenges. You need to learn how it works.

> (You see how long i am working with Star-Office, Open-Office, Libre-Office
> ;-)
> 
> The actual way is to complicate.
I guess that has to do with additional features.

> When you click on a line in the menu tab it has 3 different states - why?
I can't tell you. I think I could if I read the manual ;)

> Just make your choice of line width and type and then click on the lines you
> want to have active with this settings. This would be simple perfect.
Could work like that, if there was a state of the example without selection.

> If something is wrong then you can choose to clear all with the preset
> buttons that are already existant.
> 
> You can't find out which line width each line has - that's bad too.
> A big problem if a line is destroyed by editing old documents.
Yep - there must be an RFE for that?

> When you want to have different line width in one table it is really
> difficult to get the result you want to have.
The first thing is select the line you want to change - see the arrows.
Than if you changed the attributes and click on another line, that gets changed right away. So if you need something different there, change the settings.

> Another problem is that the line width is not rendered in a good way on the
> screen.
Indeed another problem.
Comment 21 Karsten 2019-05-10 08:42:54 UTC
(In reply to Cor Nouws from comment #20)
> (In reply to Karsten from comment #19)
> > I know you will hate my answer,
> Thanks ;)
You're welcome!
> 
> > but just have a look at the old Word / Excel 97. :-)
> Don't have them at hand and it's too long ago for me to remember.
Yes - but sometimes there are good ideas in the history.
> 
> > I never did have an problem to set my frames there.
> > The way was intuitive clear without the need of RTFM.
> I don't read the manual. but.. agreed the UI has its challenges. You need to
> learn how it works.
It's fine that you agree - maybe you will think about it. :)
> 
> > (You see how long i am working with Star-Office, Open-Office, Libre-Office
> > ;-)
> > 
> > The actual way is to complicate.
> I guess that has to do with additional features.
Additional features are fine when the basic features will not be complaint.
> 
> > When you click on a line in the menu tab it has 3 different states - why?
> I can't tell you. I think I could if I read the manual ;)
That's really funny. :)
> 
> > Just make your choice of line width and type and then click on the lines you
> > want to have active with this settings. This would be simple perfect.
> Could work like that, if there was a state of the example without selection.
Sorry - I don't understand the meaning here.
> 
> > If something is wrong then you can choose to clear all with the preset
> > buttons that are already existant.
> > 
> > You can't find out which line width each line has - that's bad too.
> > A big problem if a line is destroyed by editing old documents.
> Yep - there must be an RFE for that?
What's an RFE?
> 
> > When you want to have different line width in one table it is really
> > difficult to get the result you want to have.
> The first thing is select the line you want to change - see the arrows.
> Than if you changed the attributes and click on another line, that gets
> changed right away. So if you need something different there, change the
> settings.
In most of the cases i want to have thin inner lines and bigger lines at outline.
So it would be fine to get this in 2 steps:
1. Mark the table and set the complete thin lines.
2. Set for the same selection a bigger width of the outer lines.
2b. It should be the same when you want to highlight a part of a table with bigger outer lines.
This would be perfect.
> 
> > Another problem is that the line width is not rendered in a good way on the
> > screen.
> Indeed another problem.
Something has happened after changing to a new rendering engine :(
So maybe it is a good idea to go back to the one before?