https://bugs.documentfoundation.org/show_bug.cgi?id=173771
Bug ID: 173771
Summary: Reproducible erratic Unicode behaviour
Product: LibreOffice
Version: 26.2.5.2 release
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: LibreOffice
Assignee: [email protected]
Reporter: [email protected]
Description:
It is as if characters from different "categories" inflict indirect visual
"damage" to other characters so that some Unicode characters change their
visual appearance depending on other Unicode characters when processed by
LibreOffice.
At other times the damage also seems to be influenced by e.g. zooming,
scrolling and positioning.
I have chosen to make one report (this one), because the various cases appear
to be caused by something that has to do with the positioning, rendering and
interpretation of the characters even though the problems sometimes look
different and what causes them are different too.
However the common thing seems to be that they are Unicode characters in
various categories.
Problems have been found in Calc, Writer and Impress – there might be problems
in some of the other applications too, but that has not been tested. It turned
out that it has been easier to find and replicate various problems in Calc
although some of the same behaviour seems to occur in Writer and Impress too.
We have to start somewhere – it is fine with me in case things have to be
branched out into separate reports. We simply have to get started somewhere.
I have focused on my daily driver – using Ubuntu MATE 20.04.06 – where I run
the flatpak version of LibreOffice 26.2.5.2 (gtk3 UI) where I have made a set
of cases.
Likewise I have made a subset of these cases and tested those on Windows 11.
I have also tested Ubuntu 26.04 – both with the deb and flatpak distribution of
LibreOffice, but for now I will not go into the variances I have noticed there
– because all the various “platforms” whether Windows 11 or regardless which
old/new version of Ubuntu I have tested the issues vary. Also the issues vary
depending gtk3 or qt6 is used and whether User Interface/Tabbed UI is used in
LibreOffice.
I have simply chosen to focus on gtk3, windows and the user interface of
LibreOffice set to Tabbed UI.
So initially the various cases (using my daily driver) are described in:
"original case descriptions - LibreOffice 26.2.5.2 Ubuntu 20.04.6 MATE.txt"
, a video has been created – please watch:
https://youtu.be/otLVxsDlr2E
After the video was made I have tested the flatpak version of LibreOffice
26.8.0.3 on my daily driver. The differences can be found in the file:
"differences to video on daily driver - LibreOffice 26.8.0.3 Ubuntu 20.04.6
MATE.txt"
When I tested the 26.8.0.3 version on my daily driver I used Troubleshoot/safe
mode:
flatpak run org.libreoffice.LibreOffice –safe-mode
, but the issues seem to remain (only in some cases there are slight
differences between version 26.2.5.2 and 26.8.0.3).
Finally the video of with a reduced subset of Windows cases was made:
https://youtu.be/uOALFLAbge0
The findings explained in:
"Select cases - LibreOffice 26.8.0.3 Windows 11.txt"
# Cases in Calc
## Introduction
Possible visual artefacts to various Unicode characters:
(𝓕) = change of fonts
(👻) = visually vanishing characters (This problem differs in nature to
tdf#172646 )
(🔀) = characters in a string change position with respect to each other
(▯) = blank rectangles are shown instead of characters
(𝑓) = formula field has problems showing different characters as expected
(🔍) = zooming in/out changes the visual result
These problems often seem to happen either when:
(•) = characters are included in the same string
(‣ •) = characters in the right (hand side) cells are influenced by the left
(hand side) cells.
The erratic behaviour is hard to replicate just by pasting text into Calc – it
only works in some cases. Instead the go-to tool has been to use Data
Validation, cells of various font sizes and zooming in & out and knowing when
to not save the document/reload and when to do so!
The Data Validation tool has proven to be an important tool, because it seems
to be using the desktop UI (in gtk3) when selecting a string from a list of
possibilities, because all characters are shown as they are supposed to (only
in gtk3) whereas the formula field and the ordinary Calc cells seem to be
affected by the problems!
Because there are several examples it makes the steps to reproduce take up some
space so there are steps about how to setup the “environment” for testing (see
below) and other steps for describing and testing the individual cases
(“original case descriptions - LibreOffice 26.2.5.2 Ubuntu 20.04.6 MATE.txt”
mentioned above).
To speed up things you may use the attached test file:
"Example - B C with alternating font sizes.ods"
, and use the steps linked to above for the test cases or follow the videos.
A lot of the chosen characters are colourful (emoji) to show some of the
reproducible problems.
My best guess is that it might also affect other characters too e.g. those that
are not plain Latin letters meaning e.g. letters of other alphabets (besides
those Unicode characters chosen for the cases that might be used for more
specialised purposes/other everyday uses).
## Important
When you start please keep zoom level to 100 % unless something else is
requested.
At the end of each case please exit LibreOffice (all open documents and
LibreOffice), because else it is often not possible to reproduce the problems!
Remember not to save the document unless a case requests it as it will
influence the visual “state” of Calc and the document the next time it is
opened.
Also have no other LibreOffice documents open at the same time (including
Writer) as I have experienced that it may disturb the test cases!
The Linux video was recorded with the native screen resolution of 1366x768 – it
may or may not influence how the actual results turn out if the screen
resolution is different. Please reach out in case you would like the original
clear&crisp videos and not the YouTube videos.
The video recording from the Windows 11 computer had the native screen
resolution of 1920x1080.
# Cases in Writer and Impress
Also some cases in Writer and Impress were made which illustrate some of the
problems a bit further as they focus not only on writing, deleting and
inserting, but also problems that show up due to positioning and zooming.
# Cases, OS and differences
While the old MATE distro installation combined with the flatpak version of
LibreOffice shows almost consistent behaviour between version 26.2.5.2 and
version 26.8.0.3 then running version 26.8.0.3 on other resent Linux
distributions show more differences. E.g. in standard Ubuntu 26.04 it differs
in cases like case 8 even when running the flatpak version that uses gtk3. I
have chosen not to dive into this (at least for now), because it deserves a
video on its own.
Regarding Windows 11 it seems it does not have all the problems that is found
in Linux however characters are often missing or positioning of characters are
odd e.g. when selecting in the data validation cells as well as the font size
cells so there is definitely problems here too.
# Linux cases
## Essential cases to go through on Linux that show a lot, but not necessarily
all problems
Calc Case 5.a
Calc Case 8
Calc Cases 10.a,b,c
Writer Case 2
Impress Case 4
## Other interesting cases to go through on Linux
Calc Case 3
Calc Case 6
Calc Case 9
Impress Case 2
Impress Case 3
# Windows 11 cases
Calc Case 8
Calc Case 9
Calc Case 10.b
Impress Case 3
Impress Case 4
Steps to Reproduce:
Steps to reproduce the document for the test cases in Calc:
1. Create a new blank spreadsheet and in a sheet setup columns A, B and C for
the following:
A: Each row (from row 3 and downwards) contains the number of a font size that
will be used in columns B and C. E.g. font size 7 to 26 pt.
B: “Left” put in the top row.
C: “Right” put in the top row.
Note: Throughout the spreadsheet Liberation Sans (the default) is used.
2. Select both cells B2 and C2, right click and in the menu select “Data
validation…” and in “Allow” drop down select “List” and copy/paste the content
from the “Content for Data Validation” section below. Make sure that “Show
selection list” is ticked.
>From the drop downs of B2 and C2 select now “0. ”
3. In cells B3 and C3 apply:
=TEXTAFTER($B$2;". ")
and
=TEXTAFTER($C$2;". ")
4. Either drag down those formulas in step 3 or simply refer to the content of
=$B$3 and =$C$3 respectively. Do that until the last row of font sizes (step
1).
Make sure the font stays “Liberation Sans” in case it vanished when pasting.
5. Now for each row, but only columns B and C set the all the individual font
sizes. It is the tedious part, but it saves time later on unless one wants to
zoom in and out all the time (but it may also present an impact if omitted!)
NOTE: If you also set column A to an individual font size that matches B and C
for a particular row you will get very different, but also erratic results!
Bonus steps if you want an even more “dynamic” test experience:
6. Like in step 2. activate “Data validation…” on B2 and C2 as well as B3
until the final “font size” cell (e.g. B22).
7. Then try this bonus test setup where individual B cells are selected…
(although it overwrites the formulas of the cells it might be better for
debugging / getting an overview). From there zoom in and out and observe what
happens.
## Content for Data Validation
>>>
0.
1. Ⓕ☝️℗ⓈⒶⓁ
2. ⒻⓈⒶⓁ
3. Ⓕ☝️℗ⓈⒶⓁ⚠☹☺♖🪴🧾🚂🙭🎨🆞🆣🆫𝝿𔑲
3,5. Ⓕ℗ⓈⒶⓁ⚠☹☺♖🪴🧾🚂🙭🎨🆞🆣🆫𝝿𔑲
3,6. Ⓕ☝️℗ⓈⒶⓁ⚠☹☺♖🪴🧾🚂🙭🎨🆞🆣🆫𝝿𔑲Test
3,7. Ⓕ☝️℗ⓈⒶⓁ⚠☹☺♖🪴🧾🚂🙭🎨🆞🆣🆫👨🏿🚀𝝿𔑲
4. Ⓕ☝️℗ⓈⒶⓁ⚠☹☺
4,5. ☹☺
4,6. ☹
4,7. ☺
5. ♖🪴🧾🚂🙭🎨🆞🆣🆫𝝿𔑲
6. ♖🪴🧾🚂
6,5. ♖
7. 🙭🎨🆞🆣🆫𝝿𔑲
7,5. 🙭🆞🆣🆫𝝿𔑲
7,6. 𔑲
8. ◈
9. Ⓕ◈Ⓢ☝️
10. Ⓕ◈Ⓢ
11. ☝️
12. ☝️⚠
13. 👨🏿🚀☝️
14. Ⓕ👨🏿🚀Ⓢ
15. Ⓕ𔑲Ⓢ
16. Ⓕ🆫Ⓢ
17. Ⓕ🙭Ⓢ
18. 𔑲◈🆫🙭
19. ♖𔑲◈🆫🙭
20. ℗
21. Ⓕ℗ⓈⒶⓁ
<<<
Actual Results:
Re. the Calc cases the attached test cases demonstrated by the videos describe
whether the data validation cell of the right side or the left side should be
set first.
If e.g. right is mentioned first then the right side has to be set as the very
first thing.
The test cases describe what should be noticed, because it seems odd or
unexpected e.g. when either selecting values from the data validation cells,
navigating/positioning, selecting cells and zooming.
However there may be more situations currently unknown that may trigger these
visual artefacts/problems.
Note that when you select a string from the data validation cell (the left or
the right) it will remove the font name in the UI of Calc if the returned
string use more than one font – at least that is my experience. The actual
results using LibreOffice under gtk3, qt6 or Windows 11 differ a lot. E.g. if
the chosen LibreOffice distribution supports it (e.g. the DEB) qt6 may be
selected and run from a command prompt like: SAL_USE_VCLPLUGIN=qt6
libreoffice26.8
Expected Results:
For all cases:
1. Each character is shown without any artefacts unless no font is installed
that is able to present a specific character.
2. If a specific font has been set for a cell and that specific font has font
data for a given character then that should of course influence the visual
presentation of that character.
3. Output should yield a result that is similar to the OS/Desktop (or “better”)
when either no font or a default font has been set in a specific cell.
Meaning LibreOffice or a responsible deputy/component (e.g. HarfBuzz, FreeType,
Skia / Cairo / VCL, Fontconfig) searches for a font that matches the character
when needed and visually present it in the best way possible and at the correct
position in the text.
4. The presentation of a given Unicode character should never be influenced by
other cells nor by other characters in the cell/string unless it is expected
behaviour defined somewhere else.
Reproducible: Always
User Profile Reset: Yes
Additional Info:
# LibreOffice versions used
## Linux
Version: 26.2.5.2 (X86_64)
Build ID: cd7284b4cbbfeb507e630c1aac019f4157393acb
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: da-DK (da_DK.UTF-8); UI: en-US
Flatpak
Calc: threaded
Version: 26.8.0.3 (X86_64)
Build ID: bce0998afefdbc355585ca324285661a2170ba77
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: da-DK (da_DK.UTF-8); UI: en-US
Flatpak
Calc: threaded
## Windows
Version: 26.8.0.3 (X86_64)
Build ID: bce0998afefdbc355585ca32428566
CPU threads: 4; OS: Windows 11 X86_64 (build 26200); UI render: Skia/Raster;
VCL: win
Locale: da-DK (en_DK); UI: en-GB
Calc: threaded
--
You are receiving this mail because:
You are the assignee for the bug.
