Bug 90923 - Applying font replacement does not adapt line breaks
Summary: Applying font replacement does not adapt line breaks
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.0.0.3 release
Hardware: All All
: medium normal
Assignee: Michael Stahl (allotropia)
URL:
Whiteboard: target:5.2.0
Keywords: bibisected, bisected
Depends on:
Blocks:
 
Reported: 2015-04-29 10:44 UTC by Michael Fiedler
Modified: 2016-10-25 19:02 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
text before font replacement (65.75 KB, image/png)
2015-04-29 10:48 UTC, Michael Fiedler
Details
font replacement settings (55.69 KB, image/png)
2015-04-29 10:50 UTC, Michael Fiedler
Details
text after applying font replacement (68.11 KB, image/png)
2015-04-29 10:50 UTC, Michael Fiedler
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Fiedler 2015-04-29 10:44:40 UTC
Steps to reproduce:

1. Open a new Writer document
2. Enter a multi-line text
3. Add a font replacement rule for the font you used. E. g. if you used Liberation Serif, add a replacement rule "Liberation Serif -> Liberation Mono" in Tools > Options... > LibreOffice > Fonts > Replacement Table (enable "always" and "Apply replacement table").


Expected behaviour:

The characters are replaced by the new font and the line breaks are recalculated to fit the metrics of the new font to the page.


Observed behaviour:

The characters are replaced by the new font. However, line breaks remain at the old position, leading to lines exceeding the page margin (in case of Liberation Serif -> Liberation Mono example).


Workaround:

Reformatting all text areas, e. g. "align left" -> "center horizontally" -> "align left" recalculates line breaks.
Comment 1 Michael Fiedler 2015-04-29 10:48:29 UTC
Created attachment 115175 [details]
text before font replacement
Comment 2 Michael Fiedler 2015-04-29 10:50:01 UTC
Created attachment 115176 [details]
font replacement settings
Comment 3 Michael Fiedler 2015-04-29 10:50:32 UTC
Created attachment 115177 [details]
text after applying font replacement
Comment 4 Buovjaga 2015-04-29 17:54:36 UTC
Yep, could see the craziness even with a paragraph with no line breaks (dummy text inserted with dt + F3).

Could not repro with 3.3/3.5, so marking as regression.

Win 7 Pro 64-bit Version: 5.0.0.0.alpha1+ (x64)
Build ID: f0edb677f09ad338e22ac3b5d91497b4479e0b3c
TinderBox: Win-x86_64@42, Branch:master, Time: 2015-04-27_01:54:20
Locale: fi_FI

Ubuntu 15.04 64-bit 
OpenOffice.org 3.3.0
OOO330m20 (Build:9567)

LibreOffice 3.5.0rc3 
Build ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735
Comment 5 Matthew Francis 2015-08-14 07:23:05 UTC
This seems to have begun at the below commit.
Adding Cc: to mstahl@redhat.com; Could you possibly take a look at this one? Thanks

commit bb51791ae49ecded0f618b4534893adb8fcf917e
Author: Michael Stahl <mstahl@redhat.com>
Date:   Wed Dec 19 21:03:53 2012 +0100

    fdo#38090: vcl: remove ImplFontCache::maFontNameList:
    
    The font cache in VCL returns different fonts for identical parameters,
    which causes layout differences in Writer.
[...]
Comment 6 Robinson Tryon (qubit) 2015-12-13 11:12:21 UTC Comment hidden (obsolete)
Comment 7 Michael Stahl (allotropia) 2016-05-06 14:20:50 UTC
i'm not sure if it's fair to say that the commit in comment#5 broke this;
in 3.6.7.2 what happened is that the text was re-rendered with the new font
but evidently it wasn't re-formatted with the new font at all:
the character spacing was clearly proportional, not mono-space at all!

so what changed there is that the text is now repainted using the correct
character metrics from the new font, but not re-formatted as it should be
- probably "regression" isn't appropriate.

insert another paragraph with font actually set to "Liberation Mono"
and see the difference.

dialog: SvtFontSubstConfig::Apply()

vcl: OutputDevice::EndFontSubstitution()

sw: SwEditWin::DataChanged()

ok i think i've fixed this now for Writer for both the main document view
and print preview, if it doesn't work in other applications then please
file a new bug.
Comment 8 Commit Notification 2016-05-06 14:23:35 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=02cdd8734636ea66259fbbda395d95aa9efd7b03

tdf#90923 sw: invalidate layout when font substitutions are changed

It will be available in 5.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Daniël van Vuuren 2016-06-03 12:31:36 UTC
Verified fix in:

Version: 5.3.0.0.alpha0+
Build ID: 6b3b352b06d92ef20194b9a992a521af2ef07b48
CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; 
TinderBox: Linux-rpm_deb-x86@71-TDF, Branch:master, Time: 2016-06-03_01:35:48

Version: 5.2.0.0.beta1+
Build ID: b6230835b927e0053687fae6026fa3603600f321
CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; 
TinderBox: Linux-rpm_deb-x86@71-TDF, Branch:libreoffice-5-2, Time: 2016-06-03_02:09:38

Not fixed in:
Version: 5.1.5.0.0+
Build ID: 1245bead3a68c9495a870f194f3c523b3b78cf87
CPU Threads: 2; OS Version: Linux 4.4; UI Render: default; 
TinderBox: Linux-rpm_deb-x86@71-TDF, Branch:libreoffice-5-1, Time: 2016-06-02_04:43:39