Bug 124347 - Kerning does not work when part of a word is highlighted
Summary: Kerning does not work when part of a word is highlighted
Status: RESOLVED DUPLICATE of bug 61444
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.2.2.2 release
Hardware: All All
: medium trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
 
Reported: 2019-03-27 10:22 UTC by Nicolas Göddel
Modified: 2019-03-28 09:42 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Example of missing Kerning (6.48 KB, image/png)
2019-03-27 10:24 UTC, Nicolas Göddel
Details
spans with DF, style, and with kerning (41.37 KB, image/png)
2019-03-27 16:15 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nicolas Göddel 2019-03-27 10:22:05 UTC
Description:
When writing a word in Writer and changing the background of a part of that word the font renders differently.

Steps to Reproduce:
1. Write the word "Von" using the font "Liberation Serif"
2. Change the background color of "on" to some color
3. Now the kerning does not work anymore.

Actual Results:
The letter "o" stands apart from the "V".

Expected Results:
The Kerning between the letters "V" and "o" should still be adjusted for a visually pleasing result.


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 Nicolas Göddel 2019-03-27 10:24:00 UTC
Created attachment 150305 [details]
Example of missing Kerning

In the attachment you can see what happens after taking the steps.
Comment 2 Dieter 2019-03-27 10:54:59 UTC
I confirm it with

Version: 6.2.2.2 (x64)
Build-ID: 2b840030fec2aae0fd2658d8d4f9548af4e3518d
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; 
Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE
Calc: threaded

Correction of step 2:
choose a highlight color for "on" (not background color)
Comment 3 V Stuart Foote 2019-03-27 16:08:29 UTC
This is not a bug. When you select text from a span and apply direct formatting, or equally a style (e.g. emphasis), you are breaking the text span.

Formatting/kerning drawn from font metrics is not expected to apply in that use case--nor can it.

Here is a clip from a Flat ODT, showing the span with direct formatting or style applied.

<text:p text:style-name="P1"><text:span text:style-name="T3">V</text:span><text:span text:style-name="T4">on</text:span> <text:span text:style-name="T3">V</text:span><text:span text:style-name="Emphasis"><text:span text:style-name="T3">on</text:span></text:span> <text:span text:style-name="T3">Von</text:span></text:p>

Possible enhancment for typographic support, but IMHO not worth the dev effort to implement what would be needed to apply different formatting/style within a string.
Comment 4 V Stuart Foote 2019-03-27 16:15:49 UTC
Created attachment 150325 [details]
spans with DF, style, and with kerning

the document page for the XML snippet. 

The Emphasis style was changed from italic but a yellow highlight added to match the Direct Formatting's yellow highlight.

Point being the text span will always be broken--kerning can't be applied.
Comment 5 ⁨خالد حسني⁩ 2019-03-27 17:46:18 UTC
That is actually a bug. There is a number of formatting changes that shouldn’t break layout, color (foreground and background) is one of them. However, it is a known limitation of current LibreOffice code and I don’t think anyone is working on it. It is possibly a MS Office-compatibility issue as well, since it gets this right.

*** This bug has been marked as a duplicate of bug 61444 ***
Comment 6 Nicolas Göddel 2019-03-28 09:42:46 UTC
I understand that kerning between two different font styles will not work as there are two different fonts in most cases and there is no character based kerning mapping between fonts.
I found out about that bug as I was reading a bigger document and wanted to highlight some things and suddenly the whole document relayouted itself. Paragraphs broke at different positions, whole tables moved to other pages, and so on.
It did not found bug 61444 before which formulates the same issue in a more general way. Now that I know about it I am a bit shocked about the fact that it was already reported six years ago.