In bug 50189: "Font type picker in Format Bar should show that selected font type is not available on PC" it was sugested I file a separate enhancement request, which is this report. Bug 50189 has been resolved by two patches: http://cgit.freedesktop.org/libreoffice/core/commit/?id=0376a4c13ccffa64c938c6361a337264ad8f2b67 "if a font is not available, show its name in italic in the font combo" http://cgit.freedesktop.org/libreoffice/core/commit/?id=17d86df23e7be3ab0a161f69ff0f703728e0e135 "also change the font combo tooltip to say font is not available" The further suggested enhancement is that it would be nice if when a substitute font is being used, the "font combo tooltip" message also said which substitute font was being used.
I believe we were going to implement this font substitution tooltip for 4.0 right ? did we do that already ? :-)
Michael Meeks in comment 1 said: I believe we were going to implement this font substitution tooltip for 4.0 right ? did we do that already ? :-) My understanding is that there is a patch that will implement a tooltip to say that a font substitution has taken place: http://cgit.freedesktop.org/libreoffice/core/commit/?id=17d86df23e7be3ab0a161f69ff0f703728e0e135 This ticket is an enhancement suggestion that the tooltip should say which font is actually being used as the substitute. Otherwise we are telling the user his font is not available, but not which font is actually being used. In fact the tooltip should ideally say: * which font is not available * which one is being used as a substitute * if desired how to change which font is being used as the substitute This may be too much information...
I agree with this enhancement. Apparently, showing the substituted font name in the tool tip was never implemented, since it is still not available in LO 5.0.2 RC1. Also, it would be nice to add the ability to apply all substituted fonts to the current document, but that would probably be another report.
(In reply to tmacalp from comment #3) > I agree with this enhancement. Apparently, showing the substituted font > name in the tool tip was never implemented, since it is still not available > in LO 5.0.2 RC1. I'm sorry, I completely misread the comment above. The feature was implemented so the tooltip says that a font substitution has taken place. I agree with comment 2 that the tooltip should at least say which font is being used for the substitution.
Alternatively the actual font could be added in brackets like "Gentium (Sans)". The tooltip would a worthy enhancement but not really obvious to users (saying that in respect to #96872).
*** Bug 98650 has been marked as a duplicate of this bug. ***
Clarifying the summary Also, the enhancement could be implemented in the fontname tooltip, or more ambitiously in the combobox font listings. Either way, currently there is no UI provided means of determining the specific font substitution.
(In reply to Heiko Tietze from comment #5) > Alternatively the actual font could be added in brackets like "Gentium > (Sans)". The tooltip would a worthy enhancement but not really obvious to > users (saying that in respect to #96872). This wont always work well as the size of the combobox is small and it sometimes cant even hold the characters of a single font (e.g. Linux Libertine Display G), so users wont see the bracket substitution, i guess unless the bracket substitution will also appear in the drop down menu. So i'd recommend placing it both in the text field of the combobox and in the tooltip.
*** Bug 113176 has been marked as a duplicate of this bug. ***
*** Bug 122439 has been marked as a duplicate of this bug. ***
Changing priority back to 'medium' since the number of duplicates is lower than 5
I was opening a new bug with title "[enhancement] font substitution tooltip" but I read this META bug, so I comment here: I want to report this issue: font substitution tooltip doesn't show with which font has been substituted I attach a screenshot
Created attachment 159336 [details] tooltip doesn't show "target" font
*** Bug 138923 has been marked as a duplicate of this bug. ***
*** Bug 151010 has been marked as a duplicate of this bug. ***
*** Bug 151121 has been marked as a duplicate of this bug. ***
(In reply to V Stuart Foote from comment #7) > Clarifying the summary > > Also, the enhancement could be implemented in the fontname tooltip, or more > ambitiously in the combobox font listings. > > Either way, currently there is no UI provided means of determining the > specific font substitution. It's 2024 and people, including me, are still complaining of phantom font substitutions that cannot be determined. Word changes the font but shows the font used, not the font not installed. InDesign tells you a font isn't installed and asks which font to substitute if you don't want it to use the default font. LO Writer still never indicates a font isn't installed when the document is opened nor shows what font is substituted. Instead indicates, using the common way all other programs use including LO, it's using a font not installed - except this font which is showing in the drop down menu and tool bar is italicized. More than eleven years and counting and this is still an active bug.
In the related bug 152487, I suggest offering font family meta-data via a right-click. Right-click behavior and tooltips are "UI cousins" - both contextual to an item. Also, the substitution information for a font, or font family, is one kind of meta-data. Food for thought.
repro 26.8+ (In reply to Craig Webb from comment #17) > LO Writer still never indicates a font isn't installed when > the document is opened nor shows what font is substituted. LO now shows a warning icon by the font name (and it has long indicated a missing font by showing the name in italics). However, showing which font was used as the substitute is still not done.
I am the original reporter of this issue back on 19 February 2013. The bigger picture at the time, that I believe still applies now, is that end users expect their documents to appear the same when they, or someone else, view them on a different device. Sadly this was not always the case then, and is still not always the case today. The document foundation puts forward the ODF format as an important format that reduces "limited compatibility, vendor lock-in, and the risk of obsolescence" https://blog.documentfoundation.org/blog/2025/05/16/what-is-odf/ All of which I agree with and support. However, as far as I aware the ODF format still does not support embedded fonts. For the typical end user on a day to day basis, none of the great "features" of ODF matter if their document does not look the same on another person's device due to a missing font. LibreOffice makes the situation even worse (thought a little better today that it has been) by not making it crystal clear to the end user that a font is missing that may be affecting how the document is being displayed, and which font has been used as a substitute. If a user clearly knew a missing font was the issue, they might be able to choose a different more compatible font. As it is today, my understanding is that if a document is edited with a substitute font, when the document is saved, it is the original font that is specified in the saved document. So the cycle of incompatibility and the document looking different on different devices will probably continue. The situation gets further confused if moving between different platforms (Windows, MacOSX, Linux, Android etc), and even more so when working between different programs, ie MS Word and LibreOffice. The end user will just see differences in how the document looks that may all be due to a missing font(s), but to the end user they may just believe this LibreOffice program is not as good as MS Word because the document is not being displayed as expected. Internally LibreOffice must have a table, or decision making process, about how to substitute for a missing font. What it does not have is any method, ideally an obvious and easy to understand method, of letting the end user know what is occurring.
(In reply to junk_2010 from comment #20) > However, as far as I aware the ODF > format still does not support embedded fonts. LO does support font embedding: https://help.libreoffice.org/latest/lo/text/shared/01/prop_font_embed.html if you're having trouble with embedding fonts, check the existing bugs, blocking the meta bug 113338, or file a new one (and remember to mark it as blocking). Regardless, I agree with your emphasis on the significance of keeping the user informed about font substitutions. Unfortunately, we don't have direct mechanisms for allocating developer resources like we used to. Some "proselytizing" may be in order, e.g. a talk at one of the LO conferences, chatting on the Design Channel, talking to specific developers etc.
In comment 21 it was said: LO does support font embedding Thank-you, that is really good news. I thought that the ODF format standard itself did not support font embedding, but I guess an updated version must have added this feature then. In LibreOffice 26.2.2.2 there are two options: File -> Properties... -> Font tab Font embedding Embed fonts in the document Only embed fonts that are used in documents So all we need to do is ensure all documents have embedded fonts when they are shared, no matter which program on which system creates them :-). Might be easier said than done... I don't know how significant the increase in file size is likely to be. From the LibreOffice help: Font embedding Embed fonts in the document Mark this box to embed document fonts into the document file, for portability between different computer systems. All fonts referenced in styles or direct formatting are embedded, even if the style is not applied in the document. Only embed fonts that are used in the document Mark this box to embed fonts used in the document and filter out unused fonts. The fonts are embedded if they are used in an applied style or in direct formatting only.