At the moment, one can only specify a single font family (per language group) as part of a style. If that font are available, it will be used; otherwise, some global default fallback font is used. This is unsatisfactory, since there can be more and less appropriate fallback font family choices for different intended font families (e.g. serif and sans-serif to take a very simple example). In CSS, when specifying a font family, one can actually specify a fallback list of font family names, so that the first one available on the system rendering the page - gets used. Example: td { font-family: Lato, "Lucida Grande", Tahoma, Sans-Serif; } it should be possible to do this with ODF, and LibreOffice, as well. Naturally this is more of an advanced feature, and we should not confuse the newbie user too much, so the UI for this should not be too prominent, but I'm sure we can bikeshed something subtle.
A specific use case are Hebrew fonts: LibreOffice uses fonts from the Culmus package, specifically David CLM as the default; while Windows/MSO users don't have those by default. However - they do have the David (non-CLM) font family - which is not the default font fallback. So, it would be nice if we could say: "Use David CLM if available, otherwise David, otherwise any serif font" and the same goes for other Culmus fonts like Frank Ruehl CLM, Miriam CLM, and Aharoni CLM. I'm pretty sure this happens to some extent with Arabic fonts as well.
You already can specify any number of fallbacks, using semicolon: Foo;Comic Sans MS;bar On my system, where "Foo" (or "Bar") is not a name of an installed font, this will choose existing Comic Sans MS. INVALID? (as asking for an existing feature) Or maybe you want a better UI? Maybe the existing problem like "Arial;Helvetica" will be shown as "absent" (italicized) in the font control is the target of this issue?
(In reply to Mike Kaganski from comment #2) > You already can specify any number of fallbacks, using semicolon: > > Foo;Comic Sans MS;bar Are you sure? I just tried that and it didn't work for me. I have a font family named FF1 and don't have FF2. But when I use: FF2;FF1 in the font family combo box, I don't get FF1, just the default fallback. Same thing if I specify FF2,FF1 Same thing if I use the font selection tab in Format | Character... > INVALID? (as asking for an existing feature) At least not wholly invalid. > Or maybe you want a better UI? Well, right now the UI doesn't suggest this is supported; and Heiko just told me on the design channel that "font fallback is hard-coded" when I asked him if we have this feature"...
(In reply to Eyal Rozenberg from comment #3) > (In reply to Mike Kaganski from comment #2) > > You already can specify any number of fallbacks, using semicolon: > > > > Foo;Comic Sans MS;bar > > Are you sure? I just tried that and it didn't work for me. I have a font > family named FF1 and don't have FF2. Of course I am :-) I tested that before answering. However, I only tested with a Western text. It is possible, that this is not implemented / broken with other groups?
(In reply to Eyal Rozenberg from comment #3) > Well, right now the UI doesn't suggest this is supported; and Heiko just > told me on the design channel that "font fallback is hard-coded" when I > asked him if we have this feature"... Heh, it's no wonder people are unaware about this. It has so discoverable UI ;) The hardcoded fallback that Heiko knows about is the set of metrically compatible fonts LibreOffice knows about, which allows to het automatic substitution for Arial, TNR, Calibri, etc. - when you don't provide any fallback lists, and you have no manually defined substitutions configured in the program. What we discuss here is of course about the user-defined fallback lists.
(In reply to Mike Kaganski from comment #4) > Of course I am :-) I tested that before answering. > However, I only tested with a Western text. It is possible, that this is not > implemented / broken with other groups? Maybe, but - I tried now with the Western language font, and it again did not work for me. Build info: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 92815f3a464b447898ecf52492247335228e4a72 CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: he-IL (en_IL); UI: en-US Could it be that... * It's VCL-dependent? * It's OS-dependent? * It's somehow a recent regression, or alternatively fixed by a more recent build than mine? * You used a second font (FF2) that is the same as your default/global fallback font? Anyway, we seem to have two issues. One, why does it not work at all in some cases / on some systems, and two, having some UI visibility. Let's focus this bug on the "baseline" of it actually working consistently and split off the UI aspect of this to another bug.
Bug also manifests with Western text and build: Version: 24.2.3.2 (X86_64) / LibreOffice Community Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US
Created attachment 194509 [details] A document with two paragraphs using fallback lists The second paragraph uses Foo;Liberation Mono; the third uses Bar;DejaVu Serif. Just to exclude possibilities mentioned in comment 6.
Note that the ODF documentation of font-family attribute [1] references SVG, so the respective SVG documentation [2] applies. The SVG (and by extension, ODF) syntax uses comma. But the UI uses semicolon. [1] https://docs.oasis-open.org/office/OpenDocument/v1.3/OpenDocument-v1.3-part3-schema.html#attribute-svg_font-family [2] https://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#font-family
Created attachment 194510 [details] Screenshot of working fallback This screenshot is made using Version: 24.2.3.2 (X86_64) / LibreOffice Community Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba CPU threads: 24; OS: Windows 10.0 Build 22631; UI render: default; VCL: win Locale: en-GB (ru_RU); UI: en-GB Calc: CL threaded Indeed, given that font management is platform-specific (VCL-specific), the comment 6 may be correct. It would be useful to check using gen plugin on Linux.
(In reply to Mike Kaganski from comment #10) Just tested on a Windows 10 machine, and it worked for me. So, it is indeed a VCL/platform issue. Let's mark it as Linux, and perhaps someone can check on a Mac. There's another point, which one notices when reading the specs: The fallback list should actually involve not just the family, but all font aspects. So, for example, we should be able to say the family is "Aptos;Carlito;serif" and the size is "12;11;11" - which means: "Use Aptos 12pt if available, otherwise Carlito 11pt; otherwise any serif font at 11pt". Useful for when the metrics for the different fallbacks are different.
You have tested a fallback, where the first font is not installed and then the second font in the list is tried. That works for me on Window. I have seen a problem in case the first font is installed, but does not have the to be rendered glyph. In such case the second font should be tested for that glyph. See my screenshot, file and comments in bug 161378.
Created attachment 194990 [details] Screenshot - glyph for 1/3 not taken from the fallback-list (Comment originally by Regina) A list in the ´style:font-family´ attribute (19.532 ODF 1.3) of the <style:font-face> element (16.23 ODF 1.3) is read and written by LO. The list is available in the CharFontName property in the API and the list is shown in the drop-down list in the UI, see screenshot. The bug is, that LibreOffice does not use the list. The character 1/3 in the first line should look the same as in the second line. The character 1/3 is not contained in font "Goudy Stout" and thus it should be taken from the next font in the list, which is "Cambria". Only if it is not available in any of the fonts in the list, an implementation dependent fallback should be used.
Created attachment 194991 [details] Document used in screenshot attachment 194990 [details] (Comment originally by Regina) Open the attached file in Word, they show the ´1/3´ character correctly in font "Cambria". The first part of first line will likely look different for you, because you might not have font "Goudy Stout". To test, that the font list is not evaluated, you need a PC where the "Cambria" font is installed. Otherwise it will be correct to use for both lines the internal fallback.
(Comment originally by Regina) You might want to edit the file source to use fonts that are installed on your PC. The first one need to be a font that does not have the ´1/3´ character (U+2153), the second one a font that has the ´1/3´ character. I have chosen "Cambria" for the second font because it uses serifs for the 1 and so it easier to see when this font is not used.
(Comment originally by V Stuart Foote) Oh, ouch! Can confirm that behavior--of the font-family list sequence entered in the Character... dialog not providing the fallback sequence for missing glyph coverage, and actual fall back looks to be Win 10 os/DE system default of Segoe UI.
Hi, could you please check if bug 162072 is a duplicate of what you request here? I think so, but perhaps I miss something. Thanks.
(In reply to Miklos Vajna from comment #17) > Hi, could you please check if bug 162072 is a duplicate of what you request > here? I think so, but perhaps I miss something. Thanks. Probably not, but I can't really check before we can download attachments from BugZilla again...
(In reply to Eyal Rozenberg from comment #18) > > Hi, could you please check if bug 162072 is a duplicate of what you request > > here? I think so, but perhaps I miss something. Thanks. Your change does not make LibreOffice respect typeface fallback lists - as far as I can tell. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 01e6e4303e5a9966f102e0357fe0354a2f74a1c4 CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: he-IL (en_IL); UI: en-US
(In reply to Mike Kaganski from comment #8) > Created attachment 194509 [details] > A document with two paragraphs using fallback lists > > The second paragraph uses Foo;Liberation Mono; the third uses Bar;DejaVu > Serif. Just to exclude possibilities mentioned in comment 6. Confirmed the issue on Linux, all backends. Already in 3.5.0 (tested others like 24.2, 7.5, 7.0, 5.2). Would be interesting to hear macOS results. Arch Linux 64-bit Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 028ae168ca787e5c92560d051009a0f115911b57 CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 4 September 2024
see Khaled's comments on bug 108243, this seems a dupe.
Thanks, indeed it looks like the same. *** This bug has been marked as a duplicate of bug 108243 ***