Created attachment 111980 [details] Minimalistic repro .rtf file. Problem description: [I am not 100% sure if this behavior is to be expected or not] A default font has been set in the .rtf using the \deff0 command and by setting up a font table using \fonttbl. When ending a line with the \par command, the next line starts (as expected) with the default font as defined by \deff0 and \fonttbl. When ending a line with the \line command however, the next line starts with LibreOffice's Default Font (Western) as defined under Tool > Options > LibreOffice Writer > Basic Fonts (Western) > Default The line's text (if there is any) itself however is correctly set to use the .rtf default font. This can cause issues with empty lines whose height is then solely defined by LibreOffice's Default Font's height. Steps to reproduce: Load the attached .rtf file. Current behavior: Different fonts are set depending on the command used for ending a line. Expected behavior: The default font as defined by the .rtf itself should be used everywhere.
vmiklos - any thoughts on this one? Thanks
Cannot reproduce the font issue. The "Courier" font set in the file causes LO to display empty document and fall into the endless loop, however.
Created attachment 111991 [details] 2nd repro using a different default font (Arial). I just attached a variation of the repro file that uses the Arial font as default font. This causes the same behavior for me, i.e. it should be independent of the font set as default in the .rtf file (as long as it differs from LibreOffice's Default Font). Additional information: I can see this behavior with LibreOffice 4.1.4.2 as well.
OK I see it now.
Comment on attachment 111980 [details] Minimalistic repro .rtf file. fix mimetype
Sorry to chime in once more but I am not sure if the updated summary actually reflects what is happening here: I also see the font getting changed to the default document font in a non-empty line after a line-break. See my repro file in line 5 in the opened document (which corresponds to line 7 in the .rtf source). This line is not empty yet has the default document font on position 0.
This has also been a problem for me, mostly in pseudo-tabular layout, where empty lines are given an over-large spacing, but simple examples do not show the problem. I can fix by inserting spaces into empty lines, but the issue should be fixed properly.
Comment 7 appears to give a workaround, marking as: Minor - can slow down professional quality work but will not prevent it; Low - default This in no way changes who fixes it or in what order it is fixed. A volunteer will have to find this bug interesting enough to tackle. Minor only reflects the objective criteria that we set bugs to.
This is not just an RTF problem, or a FILEOPEN problem, but persists in document EDITING, when changes elsewhere can cause the font size to change again, even when spaces have neen inserted into those empty lines, and the containing paragraphs have been forced to the desired font size, when the document is in ODT format. In particular, adding an alphabetic index can cause that font size reversion, and when the page ends in a page break, can cause an additional page to be inserted, destroying the careful matching of lines on facing pages, and leaving the index entries out of kilter with the referenced text, once the font sizing is (again) manually restored. That might be a fault with indexing, but there's a primary instability in the font sizing, and that should be MAJOR rather than minor. A related problem reported as bug 50831 was fixed, but only (I think) for empty paragraphs, though the problem reported was also for font sizing in empty LINES, presumably following a hard line feed.
Please don't mess with severity/priority.
** 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 on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20161108
The issue is still present in 5.2.3.2 on Ubuntu 16.04 LTS.
** 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
Problem still present Version: 6.1.2.1 Build ID: 1:6.1.2~rc1-0ubuntu0.18.04.1 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); Calc: group threaded
Dear Sascha Fichtner, 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
I tested today, and can confirm that the bug still exists: Version: 6.3.2.2 Build ID: 1:6.3.2-0ubuntu0.18.04.1~lo1 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB Calc: threaded
The bug is still present. Version: 7.1.1.1 / LibreOffice Community Build ID: 575c5867c4cc13d7ae78f9ce39a54a52ed38c769 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: kf5 Locale: cs-CZ (cs_CZ.UTF-8); UI: cs-CZ Calc: threaded
This is actually a regression in 3.5.0, but predates earliest commit of bibisect-43all.
Dear Sascha Fichtner, 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
The problem is still present in 7.5.5.2 on ubuntu LTS, using Sascha's first testcase. That is to say, the empty line after \line is *visually* still reverting (wrongly) to something that looks like the default font size as set in Tools,Options,LOWriter,Basic Fonts, and changes as the size of that default font is changed, so the gap between the paragraph just ending and the paragraph following is over-large. BUT the font and size are showing correctly (or perhaps that should be 'incorrectly', or 'deceitfully'?) in the toolbar selection boxes; and inserting any text (even just a simple SPACE character) changes the line to its correct height. Fresh text in the line is displayed correctly, with the correct Courier font, as set in the RTF. So the problem seems to be in the paragraph-end itself, when following immediately after the hard-LF ?
Sorry - missed out the "About" info: Version: 7.5.5.2 (X86_64) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-GB (en_GB.UTF-8); UI: en-GB Ubuntu package version: 4:7.5.5~rc2-0ubuntu0.22.04.1~lo1 Calc: threaded
Michael Stahl committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2b47fae7e3e23ee7c733708500cb0482ad7f8af1 tdf#88214 sw: text formatting: adapt empty line at end of para to Word It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
this is a text formatting problem; should be fixed on master, also for new documents.
oh, forgot: the line height is fixed but the pilcrow symbol is still painted with the paragraph font; i didn't fix that yet because there is another problem with paragraph marker formatting not being applied and i didn't want to fix this purely cosmetic problem twice.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/570a36ad5f76ea28e0653d1a7a43250432bf1afa tdf#88214 sw: text formatting: adapt empty line at end of para to Word It will be available in 24.2.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.