Description: For bits of UI containing numbers, such as the dropdown list of point sizes or the version code, spaces are shown instead of digits. Steps to Reproduce: 1. Open a document with LibreOffice 2. Click on the font size dropdown box 3. Actual Results: All the items in the dropdown list just say "pt" Other user interface items which should contain numbers have spaces instead of digits. Digits are displayed correctly in user text within a document. Expected Results: Dropdown list should show a selection of point sizes. Reproducible: Always User Profile Reset: Yes Additional Info: [Information automatically included from LibreOffice] Locale: en-GB Module: TextDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes >libreoffice --version LibreOffice 7.1.1.2 10(Build:2) >glxinfo | grep OpenGL MESA-LOADER: failed to open nouveau (search paths /usr/lib64/dri) libGL error: failed to load driver: nouveau OpenGL vendor string: VMware, Inc. OpenGL renderer string: llvmpipe (LLVM 9.0.1, 256 bits) OpenGL core profile version string: 3.3 (Core Profile) Mesa 19.3.4 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.1 Mesa 19.3.4 OpenGL shading language version string: 1.40 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.1 Mesa 19.3.4 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10 OpenGL ES profile extensions: [nouveau was not installed because of known reliability issues.] Operating System: openSUSE Leap 15.2 KDE Plasma Version: 5.18.6 KDE Frameworks Version: 5.71.0 Qt Version: 5.12.7 Kernel Version: 5.3.18-lp152.72-default OS Type: 64-bit Processors: 8 × Intel® Core™ i7-4900MQ CPU @ 2.80GHz Memory: 15.6 GiB of RAM
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.
A fallback font is a reserve typeface containing symbols for as many Unicode characters as possible. When a display system encounters a character that is not part of the repertoire of any of the other available fonts, a symbol from a fallback font is used instead.
HEY EVERYONE <a href="https://anonigstalk.com/">anonigviewer</a> <a href="https://bingenerator.one/">bingenerator</a>
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
Dear Richard Parkins, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
The Noto Serif Hebrew font that Google currently has on their website is different from the one that I previously downloaded, and I don't still have the original version, so I can't exactly reproduce the problem. I'm currently running Open Office Version: 24.2.4.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 16; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-GB Calc: CL threaded cat /etc/os-release says NAME="openSUSE Leap" VERSION="15.5" ID="opensuse-leap" ID_LIKE="suse opensuse" VERSION_ID="15.5" PRETTY_NAME="openSUSE Leap 15.5" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:leap:15.5" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.opensuse.org/" DOCUMENTATION_URL="https://en.opensuse.org/Portal:Leap" LOGO="distributor-logo-Leap" I don't see the problem as originally reported with the current Google Noto Serif Hebrew font, but fontforge tells me that this version has glyphs for digits, which the earlier version didn't. I can't find a font with no glyphs for digits, and I don't have the time or the resources to make one. You would need to find or make one and set it as your system font in order to reproduce the problem as I reported it. I'll look and see if I can find the original Google Noto Serif Hebrew font in a backup, but I don't back up my system (as opposed to my own files) very often and I don't have time to do the searching now.
*** This bug has been marked as a duplicate of bug 73494 ***