Bug 99014 - FORMATTING: Pasting text marked with comments is wrongly formatted (see comments 7 and 8)
Summary: FORMATTING: Pasting text marked with comments is wrongly formatted (see comme...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) All
: low minor
Assignee: Not Assigned
Depends on:
Blocks: Writer-Comments
  Show dependency treegraph
Reported: 2016-04-01 06:15 UTC by Luke Kendall
Modified: 2024-04-21 03:15 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

Screen shot showing typical font error and rare blank font display (118.87 KB, image/png)
2016-04-01 06:15 UTC, Luke Kendall
Starting point ODT (26.23 KB, application/vnd.oasis.opendocument.text)
2016-04-13 10:23 UTC, Buovjaga
Sample documents to reproduce the problem (2.72 MB, application/zip)
2017-02-27 01:20 UTC, Luke Kendall
Document showing font problems after replacing paragraph styles (349.27 KB, application/vnd.oasis.opendocument.text)
2017-02-27 01:43 UTC, Luke Kendall
Screenshot showing Times New Roman after replace (213.60 KB, image/jpeg)
2017-02-28 08:15 UTC, Buovjaga
Small sample to copy from (19.75 KB, application/vnd.oasis.opendocument.text)
2022-04-21 06:55 UTC, Timur
Small sample to copy to (18.36 KB, application/vnd.oasis.opendocument.text)
2022-04-21 06:59 UTC, Timur

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kendall 2016-04-01 06:15:58 UTC
Created attachment 124003 [details]
Screen shot showing typical font error and rare blank font display

I selected the entire text of my novel and pasted it into a new document template which contained the chapter and body text paragraph styles I wished to use.  
I then used Find & Replace with Paragraph Styles selected to find and then change all instances of "Text Body" to "CSP - Chapter Body Style".

That worked fine, but on scanning the document, I find that in every place where a section of text was marked with one or more comments, the marked text in the body of the document was formatted wrongly.  Despite being ostensibly "CSP - Chapter Body Style", the font is far too large.

I note that the typeface appears to have been changed to Times New Roman and 14pt (the format in the old template, from which the text was copied).  Although sometimes if I select the commented text, blank is displayed in the fields that normally show the typeface and font size.
Please see the attached screen shot. 

Clearing the direct formatting "fixes" the problem, but wipes out any use of italics etc.  Manually selecting the text and choosing the typeface and then the style corrects the problem.

I've marked this as a major problem, as in a long document (with a thousand or so comments), and it causes a lot of busy-work.

As I scan further, I see other errors have occurred, too: occasional single paragraphs, or whole pages, that are using the old template's typeface (Times New Roman) but the new font size (10.5 rather than 14pt), even though the paragraphs are the new body text style ("CSP - Chapter Body Style").

I'm hesitant to try to find&replace all occurrences of Times New Roman 14pt to change them all to Georgia, because of this bug: https://bugs.documentfoundation.org/show_bug.cgi?id=62603#add_comment

Incidentally, although I can see Times New Roman 10.5pt text in my document, if I search for it using the F&R dialogue, it fails, reporting:
    Times New Roman, 11pt
    Search key not found
That's true.  Unfortunately, F&R was supposed to be searching for 10.5pt TNR, as selected from the menu of available font sizes, and for which many instances could be found.  It appears that F&R may also be converting fractional font sizes to integer sizes before performing its search!  Searches for Times New Roman, 14pt, for example do work.  I'll file a separate bug report for this part.  Yeah: https://bugs.documentfoundation.org/show_bug.cgi?id=64918#add_comment
Comment 1 Buovjaga 2016-04-13 10:23:14 UTC
Created attachment 124297 [details]
Starting point ODT

Not reproduced.

Attached is an example file.
1. Create new document and a new paragraph style based on Default
2. Let new style be Liberation Sans, 8pt
3. Select all in the existing document, copy and paste to the new document
4. In the new document Find and replace - Other options - Paragraph styles: find Text body and replace with your new style

Win 7 Pro 64-bit Version:
Build ID: b0e678c86136ef6d65cea66168a99217664c0278
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-04-11_23:06:28
Locale: fi-FI (fi_FI)
Comment 2 Luke Kendall 2016-04-13 13:32:21 UTC Comment hidden (obsolete)
Comment 3 Buovjaga 2016-04-13 14:20:24 UTC
(In reply to Luke Kendall from comment #2)
> Why did you try 8pt?

Because I didn't have reproduction steps and had to make them up.
Comment 4 Buovjaga 2016-04-13 14:59:41 UTC
Same result with 10,5pt font size.
Comment 5 Luke Kendall 2016-04-13 15:42:06 UTC Comment hidden (obsolete)
Comment 6 Xisco Faulí 2017-02-26 20:54:12 UTC Comment hidden (obsolete)
Comment 7 Luke Kendall 2017-02-27 01:20:06 UTC
Created attachment 131491 [details]
Sample documents to reproduce the problem

Apologies for my long delay.  Here is the template file, an obfuscated original version of the document, and the result of pasting the main body from the original into the template.

$ unzip -l Bug99014.zip
Archive:  Bug99014.zip
  Length      Date    Time    Name
---------  ---------- -----   ----
  2488756  2017-02-27 11:52   Bug99014-orig-obfusc.odt
    16446  2017-02-27 11:52   Bug99014-template.odt
   370030  2017-02-27 11:55   Bug99014-obfusc-PostPaste.odt
---------                     -------
  2875232                     3 files

An example error occurs at the beginning of Chapter 4, where the first two paragraphs have been changed to the wrong font.  (Far more than 99% of the original document correctly preserves the font of the Text Body paragraphs (Times New Roman); many of the paragraphs that are selected and marked with  a comment get the wrong font (Calibri).)

A longer example error occurs in the Prologue, where the 1st 12 pages have been changed to Calibri, and the text changes back to Times New Roman part-way through the 2nd paragraph on p13 (21).

So the steps to reproduce are:

1) Open Bug99014-orig-obfusc.odt (original)
2) Open Bug99014-template.odt (template)
3) Position cursor at start of 1st line of 1st Text Body paragraph on p2 (8) of original
4) Select from there to the end of the doc
5) Copy
6) Position cursor at start of 1st line of 1st CSP Chapter Body paragraph on p1 (9) of template
7) Select from there to the end of the doc
8) Paste
9) Save file as (e.g.) Bug99014-obfusc-PostPaste.odt

Note that on p37 (43) of original, the 1st two paragraphs of Chapter 4 are in Times New Roman, like all the others.  Compare to p86 (94) of the copied doc, and note that the 1st two paragraphs have had the font changed to Calibri.
Comment 8 Luke Kendall 2017-02-27 01:43:30 UTC
Created attachment 131492 [details]
Document showing font problems after replacing paragraph styles

I should add that I am able to reproduce the bug using my current version of Writer,, which I used to prepare the attached new example documents.

Note that the previous attachment did not include the sample document that included the file after finishing all the steps of my original report.

This attachment includes the file Bug99014-obfusc-PostPaste,ParaStyleReplace.odt which shows the original bug mentioned (I'm worried that the errors pointed out in my previous attachment are a separate bug).

Anyway, after following all the steps noted in that comment, continue as follows:

10) Open Find & Replace; Under Other Options select Paragraph Styles
11) For Find, choose Text Body
12) For Replace, select CSP Chapter Body Text
13) Click Replace All

Look for places where Times New Roman appears.
E.g. p7 (15) last paragraphs starts in EB Garamond 12 and then changes partway through into Times New Roman 14.


14) Open Find & Replace, unselect Paragraph Styles
15) Click on Format 
16) Choose Family Times New Roman
17) Choose Size 10.5 
18) Click OK - Note that the panel incorrectly says it will search for Times New Roman, 11pt
19) Set cursor on 1st line of 1st para on p1
20) Click Find Next - note that it selects a block of 14pt Times New Roman on p66 (74) for some reason, which occurs after a long run of other Times New Roman 14pt text.

Comment 9 Buovjaga 2017-02-28 08:15:53 UTC
Created attachment 131527 [details]
Screenshot showing Times New Roman after replace

Reproduced with the procedure.

Win 7 Pro 64-bit Version:
Build ID: eb7b03b052ffe8c2c577b2349987653db6c53f76
CPU threads: 4; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2017-02-26_22:34:18
Locale: fi-FI (fi_FI); Calc: CL
Comment 10 Buovjaga 2017-02-28 09:45:45 UTC
Would be great, if you could invent reliable, minimal reproduction steps.
Comment 11 QA Administrators 2018-03-01 03:41:30 UTC Comment hidden (obsolete)
Comment 12 QA Administrators 2020-03-01 03:01:13 UTC Comment hidden (obsolete)
Comment 13 QA Administrators 2022-03-02 03:48:14 UTC Comment hidden (obsolete, spam)
Comment 14 Timur 2022-04-21 06:55:18 UTC
Created attachment 179694 [details]
Small sample to copy from

Open this small 1-page sample, select all (or as in original report, from the beginning of Select from line) and copy.
Repro 7.4+. Minor issue as it can be corrected but interesting to explain.
Comment 15 Timur 2022-04-21 06:59:31 UTC
Created attachment 179695 [details]
Small sample to copy to

Select all (or as in the report, from the 1st text body paragraph) and paste what was copied from the previous document.
Comment 16 QA Administrators 2024-04-21 03:15:54 UTC
Dear Luke Kendall,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team