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.
(In reply to Regina Henschel from comment #6) > 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. 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.
(In reply to Regina Henschel from comment #6) > The bug is, that LibreOffice does not use the list. That's a different bug, actually! I didn't even know that was the case. This bug is about the UI, not the functionality. I'll open a separate bug for that...
(In reply to Regina Henschel from comment #6) Are you sure you didn't want to post this comment regarding bug 161373? That one is about the functionality not being respected, this bug is just about the UI.
(In reply to Eyal Rozenberg from comment #11) > (In reply to Regina Henschel from comment #6) > > Are you sure you didn't want to post this comment regarding bug 161373? That > one is about the functionality not being respected, this bug is just about > the UI. You are right. Comments and attachments should have gone to bug 161373.
We discussed the topic in the design meeting. The concept font family is not clear, maybe inspired by https://developer.mozilla.org/en-US/docs/Web/CSS/font-family. Users probably don't think about families but rather font names, ie. replace the font Aptos by Bierstadt. Of course we need to widen this in case the font Bierstadt is not available but it's unclear what users expect, where to make the configuration, and how to give proper feedback. We don't had the expertise in the group, and apparently the overall interest is low.
(In reply to Heiko Tietze from comment #13) Bottom line: I am thinking of giving a talk on this matter, and font substitution more generally, in this year's LOCon. > The concept font family is not clear, maybe inspired by > https://developer.mozilla.org/en-US/docs/Web/CSS/font-family. It is perhaps not clear to many of us, but it is well-know to people who write CSS; and it is mentioned and used in the ODF standard, see: https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#__RefHeading__1418066_253892949 and: https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part3-schema/OpenDocument-v1.3-os-part3-schema.html#__RefHeading__1418066_253892949 where the properties are borrowed/adopted from the XSL and SVG specifications respectively. For a bit of background and history on the terminology, have a look at: https://en.wikipedia.org/wiki/Font "In metal typesetting, a font is a particular size, weight and style of a typeface[/font family]". and then also: https://en.wikipedia.org/wiki/Typeface "A typeface (or font family) is a design of letters, numbers and other symbols, to be used in printing or for electronic display." Regardless - this bug is not about the terminology. > Users probably > don't think about families but rather font names, ie. replace the font Aptos > by Bierstadt. Aptos is a "font family", a.k.a. a "typeface". And that is what users think about. Yes, the vernacular use sometimes mixes up fonts and font families. > Of course we need to widen this in case the font Bierstadt is > not available but it's unclear what users expect, where to make the > configuration, and how to give proper feedback. This bug is not about _users_' expectations, but document _authors_' expectations (and specifications). As I mentioned in the design meeting, there are different fallback mechanisms; and this bug is about the one which the document author controls (and can be different for different pieces of content in the same document.) > We don't had the expertise > in the group, and apparently the overall interest is low. If we want to: * Edit HTML documents * Edit styled XML documents * Improve the robustness of users' employ of rare font families then we should develop this interested... Regardless, I will try to find the time to make some concrete suggestions and maybe even creake some mockups.
(In reply to Eyal Rozenberg from comment #14) > * Edit HTML documents > * Edit styled XML documents Keep in mind that we reduce HTML features and removed for example the wizard. Editing HTML is better suited for specialized tools.
(In reply to Heiko Tietze from comment #15) > Keep in mind that we reduce HTML features and removed for example the > wizard. Editing HTML is better suited for specialized tools. Heiko, do I need to repeat my "LibreOffice as a PDF editor" presentation from last year? https://events.documentfoundation.org/media/libreoffice-conference-2023/submissions/JDSEVU/resources/LO_as_PDF_editor_sbZDN5T.pdf just replace "PDF" with "HTML" everywhere... regardless of that - ODF is itself a kind of a styled XML. And standard like XHTML, CSS, XML, XSL, SVG - are some of our "forefathers" in the sens of formally-specified documents.