[Bug 161378] Improve/create visibility for font fallback lists in the UI

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=161378

Eyal Rozenberg <eyalroz1 at gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://css-tricks.com/css-
                   |                            |basics-fallback-font-stacks
                   |                            |-robust-web-typography/

--- Comment #2 from Eyal Rozenberg <eyalroz1 at gmx.com> ---
(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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.