Created attachment 54718 [details]
help->about with squares
In some cases LibO selects fonts to render the UI (regardless of the UI system fonts) with a font that doesn't support the relevant language. For Hebrew this is DejaVuSans-ExtraLight, which causes the UI to show squares instead of the Hebrew translation.
Is there a way for LibO to avoid this font for the Hebrew UI? (although I'm sure it affects more languages as this font is indeed "extra light" regarding languages support).
In recent 3.5.0 beta2, this font is included (with many others) in the lodevbasis3.5-ooofonts packages, which makes the above problem by "inherent" to all LibO builds. Changed the severity of this issue accordingly.
Beta2 changed the previous behavior, as it uses the fonts from the internal font package and seems to ignore the system font for the UI itself.
The only work around is to removed the DejaVuSans-ExtraLight font from the system (3.4.4 and 3.5.0 beta1) or from the LibO installation dir (3.5.0 beta2).
Created attachment 54719 [details]
writer with squares for UI
Created attachment 54720 [details]
output of fc-list -v
When in RTL UI the problematic font is also used as the default font for Hebrew (if culmus fonts aren't installed), meaning the text you enter also look as squares and gives impression that the software is totally broken.
For LTR interface the default Hebrew font is DejaVu Sans (no culmus fonts installed) or Nachlieli when the culmus fonts are installed (which is fine).
the hard bit with these is reproducing it, it depends so much on the fonts installed what falls back to what
I know, but this is more of an issue of not selecting fonts which don't include support. DejaVuSans have many fonts to choose from, not need to select the only one without Hebrew support.
it just doesn't work like that
Tried matching my fonts as closely as possible with the output of fc-list, but can't reproduce this locally. What's the desktop environment, gnome2, gnome3 or something else ? What's the desktop default font set to ? just "Sans" or something specific ?
This has got to be basically be the same as bug #44078 which I can reproduce, and understand the problem behind.
bah, bug 44492 I mean
I'm not sure they are the same, as we talk about UI font instead of document content font. The code might be close, but is in use in different parts of the software.
*** Bug 44492 has been marked as a duplicate of this bug. ***
I'm fairly confident they're the same thing.
Will try to test on daily builds, as this won't be included in beta3.
suggested for cherry-picking to 3-4 series
Verified with 3.5.0 RC1.
Any news about the 3.4 branch ?