Bug 88214 - FILEOPEN RTF: Empty lines after line breaks have the default document font
Summary: FILEOPEN RTF: Empty lines after line breaks have the default document font
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
3.5.0 release
Hardware: All All
: low minor
Assignee: Not Assigned
Keywords: filter:rtf, preBibisect, regression
Depends on:
Blocks: RTF-New-Import RTF-Paragraph
  Show dependency treegraph
Reported: 2015-01-08 22:56 UTC by Sascha Fichtner
Modified: 2023-07-27 08:43 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Minimalistic repro .rtf file. (570 bytes, application/rtf)
2015-01-08 22:56 UTC, Sascha Fichtner
2nd repro using a different default font (Arial). (568 bytes, application/rtf)
2015-01-09 09:02 UTC, Sascha Fichtner

Note You need to log in before you can comment on or make changes to this bug.
Description Sascha Fichtner 2015-01-08 22:56:33 UTC
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.
Comment 1 Joel Madero 2015-01-08 23:04:11 UTC
vmiklos - any thoughts on this one? Thanks
Comment 2 Urmas 2015-01-09 04:49:49 UTC
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.
Comment 3 Sascha Fichtner 2015-01-09 09:02:11 UTC
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 as well.
Comment 4 Urmas 2015-01-09 17:27:50 UTC
OK I see it now.
Comment 5 Robinson Tryon (qubit) 2015-01-14 22:32:31 UTC
Comment on attachment 111980 [details]
Minimalistic repro .rtf file.

fix mimetype
Comment 6 Sascha Fichtner 2015-01-14 23:32:55 UTC
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.
Comment 7 Bernard Moreton 2015-08-10 09:17:34 UTC
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 8 Joel Madero 2015-08-11 02:25:22 UTC
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.
Comment 9 Bernard Moreton 2015-09-24 08:58:26 UTC
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.
Comment 10 Joel Madero 2015-09-24 15:03:24 UTC
Please don't mess with severity/priority.
Comment 11 QA Administrators 2016-11-08 10:37:53 UTC Comment hidden (obsolete)
Comment 12 Bernard Moreton 2016-11-09 11:03:21 UTC
The issue is still present in on Ubuntu 16.04 LTS.
Comment 13 QA Administrators 2018-10-23 02:48:19 UTC Comment hidden (obsolete)
Comment 14 Bernard Moreton 2018-10-24 12:58:55 UTC
Problem still present
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
Comment 15 QA Administrators 2019-10-25 02:40:50 UTC Comment hidden (obsolete)
Comment 16 Bernard Moreton 2019-11-06 10:33:56 UTC
I tested today, and can confirm that the bug still exists:
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
Comment 17 Svatopluk Vít 2021-03-01 10:02:07 UTC
The bug is still present.

Version: / 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
Comment 18 Aron Budea 2021-07-26 03:47:43 UTC
This is actually a regression in 3.5.0, but predates earliest commit of bibisect-43all.
Comment 19 QA Administrators 2023-07-27 03:15:47 UTC Comment hidden (obsolete)
Comment 20 Bernard Moreton 2023-07-27 08:42:21 UTC
The problem is still present in 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 ?
Comment 21 Bernard Moreton 2023-07-27 08:43:54 UTC
Sorry - missed out the "About" info:
Version: (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