Bug 142236

Created attachment 171919 [details]
Output from YaST hardware info

Created attachment 171920 [details]
Screenshot of About LibreOffice

Note spaces instead of digits in version number

Can't reproduce this.

Version: 7.1.1.2 / LibreOffice Community
Build ID: fe0b08f4af1bacafe4c7ecc87ce55bb426164676
CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: gtk3
Locale: en-IN (en_IN); UI: en-US
Calc: threaded

The numbers are displaying correctly for both the "Font Size Dropdown" as well as "About LibreOffice" on my Windows 10 environment.

Version: 7.1.2.2 (x64) / LibreOffice Community
Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4
CPU threads: 8; OS: Windows 10.0 Build 19042; UI render: default; VCL: win
Locale: en-GB (en_US); UI: en-US
Calc: CL

This problem appeared when I upgraded from OpenSUSE LEAP 15.1 to OpenSUSE Leap 15.2: this presumably involved a version upgrade of LibreOffice as well, although I can't confirm that for certain.

The problem occurs only for certain choices of system font: I have found it with these

Droid Arabic Kufi
Droid Arabic Naskh
Droid Sans Armenian
Droid Sans Ethiopic
Droid Sans Hebrew
Droid Sans Japanese
Doid Sans Thai
Goha-Tibeb Zemen
Guseul
Noto Serif Hebrew

but there may be others. Note that all these fonts are optimised for non-Latin scripts, although of course they all have a full set of basic glyphs.

I have not found any other applications which use the system font to be affected.

LibreOffice Calc also shows the problem: with any of these fonts as the system font there are no row numbers (you need to restart to show this) and the numbers in the point size list are missing. If I set the font for a cell to one of these fonts, all the digits in the cell are replaced by wide spaces, but the digits are still correctly displayed in the input line box in the toolbar (!)

LibreOffice Writer also loses digits in text if I set the text's font to be one of those above.

I could of course use a system font which doesn't show this problem with LibreOffice, but it is definitely a problem with LibreOffice since it only showed up when I upgraded.

I do a lot of work with Biblical Hebrew text, and I want things like file names in Hebrew to show up in the traditional font, not a modern one. However most traditional Hebrew fonts use serif glyphs for Latin characters, and I prefer a sans-serif font for general User Interface elements. Noto Serif Hebrew is the only font that I have been able to find that combines sans-serif glyphs for Latin text with traditional glyphs for Hebrew text, so it is a real inconvenience if I can't use it. I was using it before my operating system upgrade without problems.

OK, I now have a better idea of what is happening here. I looked at Noto Serif Hebrew with a font viewer and it only has glyphs defined for Hebrew characters. Presumably when a non-Hebrew character is to be rendered, somewhere between the text to be shown by the application and the pixels on the screen something chooses another font which has a glyph for that character in order to render it.

Most applications get that right. The LibreOffice version that came with OpenSUSE Leap 15.1 gets it right. The LibreOffice version that comes with OpenSUSE Leap 15.2 doesn't get it right.

An acceptable workaround for me would be to construct a font which has the glyphs for Hebrew characters from Noto Serif Hebrew, and the remaining glyphs from some sans-serif font that I'm happy with. The last time I (wrote and) used a font editor (for a laser printer) was about 35 years ago. Font formats have changed a lot since then. Any help in doing this (what tool to use, how to drive it) would be welcome. I can eventually work it out for myself, but why reinvent the wheel?

Of course it would be better if LibreOffice gets fixed to do it right again.

(In reply to Richard Parkins from comment #6)
> OK, I now have a better idea of what is happening here. I looked at Noto
> Serif Hebrew with a font viewer and it only has glyphs defined for Hebrew
> characters. Presumably when a non-Hebrew character is to be rendered,
> somewhere between the text to be shown by the application and the pixels on
> the screen something chooses another font which has a glyph for that
> character in order to render it.
> 
> Most applications get that right. The LibreOffice version that came with
> OpenSUSE Leap 15.1 gets it right. The LibreOffice version that comes with
> OpenSUSE Leap 15.2 doesn't get it right.

Based on this, it seems 15.1 had version 7.0: http://download.opensuse.org/repositories/LibreOffice:/7.0/

Old versions are available for testing, also as appimages:
https://libreoffice.soluzioniopen.com/old-versions/

Could you test version 7.0 on your current Leap:
https://libreoffice.soluzioniopen.com/old/LibreOffice-7.0.0-x86_64.AppImage

Appimages are executable files, like portable software.

If you don't see the problem with version 7.0 in your current Leap, then it would indeed seem to be a problem with LibreOffice itself, appearing between 7.0 and 7.1.

With

Version: 7.2.5.1 / LibreOffice Community
Build ID: 20(Build:1)
CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: kf5 (cairo+xcb)
Locale: en-GB (en_GB.UTF-8); UI: en-GB
Calc: threaded

running on

NAME="openSUSE Leap"
VERSION="15.3"
ID="opensuse-leap"
ID_LIKE="suse opensuse"
VERSION_ID="15.3"
PRETTY_NAME="openSUSE Leap 15.3"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:leap:15.3"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"

the behaviour is even more peculiar. Spreadsheet row numbers and point sizes in both Writer and Calc whose first digit is 9 are not displayed. Other numbers, including those with 9 as non-first digit, are displayed correctly. Sometimes numbers with first digit 7 are displayed, and sometimes not: I haven't been able to characterise the circumstances.

Also when a spreadsheet cell is selected and the row number at the left becomes highlighted, the row number disappears.

In https://libreoffice.soluzioniopen.com/old/LibreOffice-7.0.0-x86_64.AppImage,
the row number highlighting problem is present (so that bug was in 7.0), but the missing number problem isn't present (so that bug appeared between 7.0 and 7.1, and is partially fixed for some numbers in 7.2).

I did mange to work around this on my own machine by constructing a font from a suitable sans-serif font with the Hebrew glyphs replaced by the ones that I wanted from Noto Serif Hebrew. However LibreOffice should get it right for people who can't work out how to make tehir own font.

Richard, a new major release of LO has been released since your last test. So could you please retest with LO 24.2? Thank you.
=> NEEDINFO