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
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: 5.2.0.0.alpha0+ 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)
Why did you try 8pt? I think the problem, only occurs if the font size you're searching for is non-integral (x.5 point).
(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.
Same result with 10,5pt font size.
(In reply to Buovjaga from comment #4) > Same result with 10,5pt font size. Huh. I have a deadline tomorrow; I'll try to prepare a sample document, then, with detailed steps for reproducing it, on Friday.
(In reply to Luke Kendall from comment #5) > (In reply to Buovjaga from comment #4) > > Same result with 10,5pt font size. > > Huh. I have a deadline tomorrow; I'll try to prepare a sample document, > then, with detailed steps for reproducing it, on Friday. Setting to NEEDINFO until the sample document and the steps are provided.
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.
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, 5.2.5.1, 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. Also: 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. 2)
Created attachment 131527 [details] Screenshot showing Times New Roman after replace Reproduced with the procedure. Win 7 Pro 64-bit Version: 5.4.0.0.alpha0+ 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
Would be great, if you could invent reliable, minimal reproduction steps.
** Please read this message in its entirety before responding ** 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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 MassPing-UntouchedBug
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.
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.