Bug 155475 - Incorrect displaying of some text in Writer, while it is OK in exported PDF
Summary: Incorrect displaying of some text in Writer, while it is OK in exported PDF
Status: RESOLVED DUPLICATE of bug 150398
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.4.7.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
 
Reported: 2023-05-24 16:30 UTC by klemens_czajka
Modified: 2023-06-01 13:02 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
.odt and .pdf test files (20.62 KB, application/x-zip-compressed)
2023-05-24 16:35 UTC, klemens_czajka
Details

Note You need to log in before you can comment on or make changes to this bug.
Description klemens_czajka 2023-05-24 16:30:24 UTC
Description:
I wrote a string of several characters ⚫ (U+26AB) in the line, alternating with different colors. By setting the background color of the lines to one color of characters, I wanted to make some characters disappear against this background, so as to simulate the spacing of exactly the width of the characters. Unfortunately, with the release of some new version of Libreoffice Writer, this effect is incorrectly displayed in the editor. However, interestingly, after exporting the text to a PDF file, the effect is correct. In my opinion, this indicates some small mistake in the part of the program responsible for displaying the edited text on the screen.
I have attached a sample file "test Libre Office.odt" and created via "Export as" --> "Export as PDF" file "test Libre Office.pdf".

Steps to Reproduce:
1. In Libreoffice Writer write a line of characters, for example:
AAAAA⚫⚫⚫⚫⚫

2. Set color of each odd character to red,

3. Set color of line background also to red. All odd "A" letters disappear, but all circles are still visible. You can save document and reedit - effect is the same.

4. "Export as" --> "Export as PDF" - all odd characters in the PDF are invisible.

Actual Results:
The ⚫⚫⚫⚫⚫ characters do not recolor

Expected Results:
The ⚫⚫⚫⚫⚫ characters should appear in set character color


Reproducible: Always


User Profile Reset: No

Additional Info:
Charactes on screen in editor should appear in set color.
Comment 1 klemens_czajka 2023-05-24 16:35:34 UTC
Created attachment 187482 [details]
.odt and .pdf test files
Comment 2 raal 2023-05-28 19:33:02 UTC
I can confirm with Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 578758835e700b38b167753ccda9527f3a8cc43b
CPU threads: 4; OS: Linux 5.19; UI render: default; VCL: gtk3
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded

In Version: 4.3.0.0.alpha1+
Build ID: 8f97326bdd3f42fc82aa5e1989fd03b0af1daf64  some of the characters are grey
Comment 3 raal 2023-05-28 19:40:35 UTC
This seems to have begun at the below commit in bibisect repository/OS bibisect-linux-64-6.4.
Adding Cc: to Caolán McNamara ; Could you possibly take a look at this one?
Thanks
 1c882d32a789d01830236149fee70b12f00d6380 is the first bad commit
commit 1c882d32a789d01830236149fee70b12f00d6380
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Wed Sep 4 22:29:45 2019 +0200

    source 29411e7c08ec249116ee0211888e47c8b6f57707

78600: Related: rhbz#1648281 improve fontconfig fallback for emojis | https://gerrit.libreoffice.org/c/core/+/78600
Comment 4 ⁨خالد حسني⁩ 2023-06-01 13:02:08 UTC
U+26AB is an emoji codepoint with default Emoji presentation, which means it should be rendered in color which happens by using a color emoji font. When a color font is used, colors set in the application are ignored.

The PDF export matches the screen rendering in 7.5.

If you want to render it using a non-color font, currently the only way is to explicitly specify such font and not depend on font fallback. Bug 150398 tracks the ability to select emoji presentation in a more flexible way.

You may also try to use another circle code point that is not an emoji, e.g. ⬤ U+2B24.

*** This bug has been marked as a duplicate of bug 150398 ***