Bug 34661 - Paragraph indent problem when inserting text
Summary: Paragraph indent problem when inserting text
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium minor
Assignee: Not Assigned
Depends on:
Blocks: Paste Writer-UX Formatting-Text-Diverse
  Show dependency treegraph
Reported: 2011-02-24 04:55 UTC by sasha.libreoffice
Modified: 2019-08-31 10:37 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:

when pasted, last string becomes with different indent (9.49 KB, application/vnd.oasis.opendocument.text)
2011-02-24 04:55 UTC, sasha.libreoffice
Test file with first line indent (not reproducable, (9.78 KB, application/vnd.oasis.opendocument.text)
2017-05-23 13:08 UTC, Thomas Lendo
Test file with last line indent ( (12.85 KB, application/vnd.oasis.opendocument.text)
2017-05-23 13:09 UTC, Thomas Lendo

Note You need to log in before you can comment on or make changes to this bug.
Description sasha.libreoffice 2011-02-24 04:55:14 UTC
Created attachment 43747 [details]
when pasted, last string becomes with different indent

I have created new document and increased paragraph indent.
Then opened help, selected 3 strings, copied and pasted in document.
Firs 2 string become with no indent, as was in help, but 3-th become with increased indent.
I think, that most users expect, that all pasted string should be with identical indent. Because in source document they are identical.

I know that it is because last pasted string has no paragraph character. But I think for it should be applied paragraph properties as in lines above.
Comment 1 Rainer Bielefeld Retired 2011-05-16 08:36:15 UTC
Still reproducible with "LibreOffice 3.4Beta5  – WIN7  Home Premium  (64bit) German UI [DEV300m103 (Build:5)]"
Comment 2 Björn Michaelsen 2011-12-23 11:51:35 UTC Comment hidden (obsolete)
Comment 3 sasha.libreoffice 2011-12-28 22:55:15 UTC
reproducible on LibO 3.5.0 beta 1
But behaves different: Instead of last line wrong in 3.3.1, in 3.5.0 wrong is first line
Comment 4 Rainer Bielefeld Retired 2011-12-29 00:39:50 UTC
Still [Reproducible] with "LibreOffice 3.4.5 RC1  - WIN7 Home Premium (64bit) German UI [Build ID: OOO340m1 (Build:501)]" as in original report.

I confirm latest observations with Parallel Dev-Installation of  "LibreOffice 3.5.0 Beta2- WIN7 Home Premium (64bit) German UI [Build-ID : 8589e48-760cc4d-f39cf3d-1b2857e-60db978]
now the first line instead of last one shows different indent when I copy / paste Help from LibO 3.4.5(!) to "NewSample.odt" page 2 document opened in 3.5.0. 
Copy / Paste the same links from LibO 3.5 Help behaves as per original report and has the extra indent in the last line.

Effect is not limited to copy/paste from help, following steps shows a related effect:

Steps to reproduce effect similar to original report:
0. Start LibO
1. Open "NesSample.odt" from Start Center File menu
2. Select / Mark 3 lines on first page Moving mouse pointer with pushed left
   mouse button
   > all text Highlighted
3. <control+c> for copy
4. Scroll to page 2, click into first line
   > Caret flashes in first line
5.  <control+v> for paste
   Expected: formatting properties from first page text overwrite
             indent from second page
   Actual: expection only correct for first 2 lines, third one keeps indent

This new sample shows the same effect with 3.4.5 and 3.5.5

All the same with OOo 3.1.1, so inherited from OOo

Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
Comment 5 sasha.libreoffice 2012-05-02 06:53:10 UTC
reproduced in 3.5.3 on Fedora 64 bit
Comment 6 QA Administrators 2015-04-01 14:41:44 UTC Comment hidden (obsolete)
Comment 7 tommy27 2016-04-16 07:28:02 UTC Comment hidden (obsolete)
Comment 8 QA Administrators 2017-05-22 13:25:34 UTC Comment hidden (obsolete)
Comment 9 Thomas Lendo 2017-05-23 13:06:13 UTC
I did the same as described in comment 1:
1. open new document
2. increase the indent of the paragraph manually (changing styles doesn't show this behavior)
3. insert multi-line text from another document/web page/etc.

Actual result:

- Multi-line text inserted as unformatted text is inserted with the indent in all lines 
(that's correct).
- Sometimes: Multi-line text inserted as normal text incl. formatting is inserted as formatted in the source except the __last__ line where the indent is applied.
- Sometimes: Multi-line text inserted as normal text incl. formatting is inserted as formatted in the source except the __first__ line where the indent is applied.

Expected result:

The inserted text incl. formatting should be shown identical as in the source.
MSO Word inserted the formatted text and pushes the existing other-formatted line into a new paragraph below so that the inserted text is shown as in the source and the user-formatted line isn't lost. I think this is a behavior users can live with.

Asking UX for input.

Tested with version
Build ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448
CPU Threads: 8; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; Locale: de-DE (de_DE); Calc: CL
Comment 10 Thomas Lendo 2017-05-23 13:08:45 UTC
Created attachment 133477 [details]
Test file with first line indent (not reproducable,
Comment 11 Thomas Lendo 2017-05-23 13:09:09 UTC
Created attachment 133478 [details]
Test file with last line indent (
Comment 12 Heiko Tietze 2018-04-20 15:03:12 UTC
(In reply to Thomas Lendo from comment #9)
> - Sometimes: ... except the __last__ line 
> - Sometimes: ... except the __first__ line
> Expected result:
> The inserted text incl. formatting should be shown identical as in the
> source.

Sounds to me like fun for QA but a question to UX.
Comment 13 Timur 2018-07-06 12:08:15 UTC
This looks like a duplicate of Bug 68271.
Please write reproducible steps.
Comment 14 QA Administrators 2019-01-11 15:22:37 UTC Comment hidden (obsolete)
Comment 15 QA Administrators 2019-03-21 11:25:30 UTC
Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team