The ODF format supports [1] setting not not just single fonts, but lists of fallback font families, so that if some of the families are not available with the appropriate features on the system, the next list item would be chose. This is intended to make font choices more robust for display on systems which don't have the same installed fonts as the author's. In fact, the list notation can be used for all aspects of a font, so that it's not just a fallback among families, but among complete font descriptions. Now, here's the UI situation, as I see it: * The UI does not represent the nature of the font info as a list of (tuples of) items - even when the current selection actually has non-degenerate list (i.e. more than 1 item). * One can type in multiple font families, separated by a semicolon - but not all (and perhaps not any) other aspects of the font. For example, if one types "12;11" as the font size, this is replaced with the maximum value, 999.9 pt, for some reason. * The font family combo-box always (AFAICT) shows lists of font-families as missing or existing based on the first item on the list. * There is no mechanism for collapsing and uncollapsing the list in the family combo-box, to show only the first item, or only the first available item. * There is no mechanism for scrolling the list in the family combo-box. I am not suggesting any specific action be taken, but I am suggesting that _some_ action be taken to make it possible for users who need it actually to work with font fallback lists. [1] https://docs.oasis-open.org/office/OpenDocument/v1.3/OpenDocument-v1.3-part3-schema.html#attribute-svg_font-family ; and that directs you to: https://www.w3.org/TR/2008/REC-CSS2-20080411/fonts.html#font-family
(In reply to Eyal Rozenberg from comment #0) > * The UI does not represent the nature of the font info Whatever that means it's not a user-centric design. > * One can type in multiple font families... > * The font family combo-box... Can you explain what you are trying to achieve and what blocks you are facing. Rather than "make the dropdown a list". There are a lot of duplicate reports asking for improvements around font substitution. See for example bug 146291 Allow use of substituted font as if it were installed bug 78186 Add an easy way to know which fonts are used in a document and which of them are missing bug 96872 Make it more obvious that a font has been substituted bug 104667 Font substitution mechanism for import formats and read https://design.blog.documentfoundation.org/2016/10/21/dealing-with-missing-fonts/
(In reply to Heiko Tietze from comment #1) > Whatever that means it's not a user-centric design. Uh, I guess, although I'm not sure I have a good grasp of how a "user-centric" design is defined. > Can you explain what you are trying to achieve and what blocks you are > facing. Rather than "make the dropdown a list". Let me try; and let's focus on font families only to make it simpler. Generally, the font family selection is not a single font family, it's a list. For a not-so-long explanation, see here: https://css-tricks.com/css-basics-fallback-font-stacks-robust-web-typography/ and an example would be: Lato, "Lucida Grande", Tahoma, Sans-Serif; so, 4 elements, each of which is a font family. However, our UI is well-designed for selecting a single font family; we don't have UI elements for manipulating lists of font-families, nor even for easier display of these list, which are typically longer than our box width. Displaying a potentially-long list typically means supporting moving or scrolling among the various items, plus clearly distinguishing subsequent items from each other. And there is the matter of representing information such as which list item is currently selected, which are unavailable on the system, the ability to _only_ see the selected item etc. Now, our situation here is tricky, because accommodating the list-nature of font-family selection will very likely burden the typical user, who does not want to / need to know about font family fallback lists. So it's not as though one can make a straightforward suggestion regarding how to proceed; it requires some brainstorming. And now let's also remove our simplifying assumption that this is just about the font family. Actually, most/all aspects of the font can also be different for different elements on the list. So font choice is not, e.g. "choice of size, listof(choice of family)", it is actually "listof(choice of size, choice of family)". And our UI _definitely_ does not hint at anything like that being the case. > There are a lot of ...reports asking for improvements around font > substitution. Indeed, but - this is not the same thing as font substitution. Even if we had _no_ global font substitution mechanism, this issue would be just as relevant. > bug 146291 Allow use of substituted font as if it were installed Slightly related, since font-families (or rather fonts) on fallback lists could also be made usable as though they were installed, but I doubt anyone would ask for that. So basically irrelevant > bug 78186 Add an easy way to know which fonts are used in a document and > which of them are missing That bug is about the document as a whole, and about separate UI for that purpose, while this bug is about the main character formatting UI widgets, and about the current selection. That said, bug 78186 is more complex to correctly resolve when one also considers font fallback lists. Are items on the list before the selected one considered missing, even though they are not effectively in use? What about items _after_ the selected one? > bug 96872 Make it more obvious that a font has been substituted Related, but with fallback lists, what we typically get is not substitution with some global default, but a choice of the first available font on the list. Very often, the last item on the list is a "can't be missing" item, like "serif" or "sans serif", and a LibreOffice installation always bundles some fonts to satisfy one of those selectors. > bug 104667 Font substitution mechanism for import formats Related to font fallback lists (as such a mechanism could result in generating fallback lists rather than outright substitution), but it's not related to this bug in particular.
ODF and LibreOffice do not work against Font "families" they work against named font-faces (aka typeface). With the fallback sequence of named font-faces listed per local in VCL.xcu IMHO, see no reason to adjust or expand usage to implement the loose organization of font-faces into families just to provide some semblance of CSS2 'Font family' when our ODF named 'font-face' listing is sufficient. It might be feasible to expose the VCL.xcu font-face listing to user customization directly, but beyond that see nothing to be achieved here beyond current VCL.xcu fallback. Of course we could use expanded Listbox/dialog handling of variant named font-face weights, and fallback for variable fonts, but that is not the font family listing of OP.
(In reply to V Stuart Foote from comment #3) > ODF and LibreOffice do not work against Font "families" they work against > named font-faces (aka typeface). With the fallback sequence of named > font-faces listed per local in VCL.xcu I believe these are two terms for the same thing; see: https://developer.mozilla.org/en-US/docs/Web/CSS/font-family this bug is not about that, it's about lists of font families, or to use your term, lists of font faces. These lists are supported, but not well-represented in the UI.
(In reply to Eyal Rozenberg from comment #4) > ... > this bug is not about that, it's about lists of font families, or to use > your term, lists of font faces. These lists are supported, but not > well-represented in the UI. As I said: > It might be feasible to expose the VCL.xcu font-face listing to user > customization directly, but beyond that see nothing to be achieved here > beyond current VCL.xcu fallback. >
Created attachment 194979 [details] Screenshot 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 194980 [details] File that was used for the screenshot 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.
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.