Bug 146291 - Allow to use substituted font as if it were installed
Summary: Allow to use substituted font as if it were installed
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Font-Substitution
  Show dependency treegraph
 
Reported: 2021-12-18 00:52 UTC by Aron Budea
Modified: 2022-12-07 10:54 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aron Budea 2021-12-18 00:52:52 UTC
When you open a document with missing fonts (eg. it using Calibri on a system that doesn't have MS Office installed), the font name is shown in italic in the font picker. However that font can't be set, if a piece of text is in a different font, the other font won't appear in the font picker.

Since you might want to pass a file between LibreOffice and MS Office, it'd be nice if the user was allowed to freely "use" those missing fonts, and then when opened in Word, those changes will appear in the familiar font.

Or one could even set up their font substitution table for the common MS fonts they want to use regularly, and in LO those font names could appear in the font list and be used even when starting an empty document.
Comment 1 Mike Kaganski 2021-12-18 05:15:15 UTC
1. You may enter any name into the box, and it will be "used" and substituted on the system where that name is missing, and will be saved. Adding document fonts to the list is IMO wrong, since using "italics" is not enough to disambiguate the font from other fonts also using "preview" in drop-down.

2. You also may use Carlito, and the Carlito will be used as main font, but Calibri will be also written to the file as fallback - since LO knows about that.

WF IMO...
Comment 2 Mike Kaganski 2021-12-18 06:59:11 UTC
(In reply to Mike Kaganski from comment #1)
> Adding document fonts to the list is IMO wrong, since using "italics" is not
> enough to disambiguate the font from other fonts also using "preview" in
> drop-down.

OTOH, simply having a specific decoration for the missing font in the preview list, like some icon, would do the trick.
Comment 3 Aron Budea 2021-12-18 10:48:36 UTC
(In reply to Mike Kaganski from comment #1)
> 1. You may enter any name into the box, and it will be "used" and
> substituted on the system where that name is missing, and will be saved.
> Adding document fonts to the list is IMO wrong, since using "italics" is not
> enough to disambiguate the font from other fonts also using "preview" in
> drop-down.
Having a free-text entry for the font isn't particularly user-friendly, is it?
I agree that substituted document fonts shouldn't be placed among the other fonts, but they could appear eg. at the top of the list, between the last used fonts and the system fonts. On the other hand LO-wide substitution, based on the config could appear normally in the list, think of it like an alias (the fact that it's a substituted font still has to be indicated in some way, of course).

> 2. You also may use Carlito, and the Carlito will be used as main font, but
> Calibri will be also written to the file as fallback - since LO knows about
> that.
You can't expect random users to be familiar with the common metric-compatible replacement fonts.
Comment 4 Aron Budea 2022-03-31 17:37:37 UTC
Let's add the UX team for input.
Comment 5 V Stuart Foote 2022-03-31 18:26:07 UTC
But wait, the "missing" font comes in recorded into the style which can already be selected for continued use in the document. And IIRC for interoperability & stability that PS or CS gets written back out with the "missing" font--not with the intentional font substitution (i.e. by dialog) or result of an os/DE driven fallback mechanism. Print or export to PDF may be an issue--but the ODF or OOXML should retain the missing font assignment to its spans.

And isn't this really a duplicate of bug 96872 and the UX-Design workup in https://design.blog.documentfoundation.org/2016/10/21/dealing-with-missing-fonts/
Comment 6 Aron Budea 2022-03-31 23:07:54 UTC
(In reply to V Stuart Foote from comment #5)
> But wait, the "missing" font comes in recorded into the style which can
> already be selected for continued use in the document. And IIRC for
That seems to be a bit restricted to me, what if the document creator didn't use styles, or you want to create new styles with the same font?

> And isn't this really a duplicate of bug 96872 and the UX-Design workup in
> https://design.blog.documentfoundation.org/2016/10/21/dealing-with-missing-
> fonts/
I see no mention that a substituted font can be referred to as if it was installed (eg. picked from font selector), but please point me to it if I missed it.
Comment 7 Heiko Tietze 2022-04-01 07:59:05 UTC
Don't think we need a ticket for every single aspect in case of (extensive) enhancements. The solution is outlined in bug 96872 and the blog post as well as many other tickets around font management.

* bug 78186 - Add an easy way to know which fonts are used in a document and which of them are missing
* bug 61134 - Font substitute name should appear in the font name combobox and in its tooltip
* bug 100900 - [Enhancement] inform user when a font style doesn't exist (bold, italic,...)
* bug 104667 - Font substitution mechanism for import formats

* bug 103342 - [META] Font substitution bugs and enhancements
Comment 8 Aron Budea 2022-04-01 13:10:39 UTC
I completely agree. The reason for the bug report is that none of the existing ones seem to have dealt with how to use the not existing font in the document, eg. pick it from the font picker. The comments in this report seem to confirm this isn't something people usually consider when when it comes to the feature as a whole, so my conclusion is that it's worth a direct mention.
Comment 9 Mike Kaganski 2022-04-01 14:22:27 UTC
Thinking about providing a used-in-the-document-but-missing font in the font list, I suppose that it shouldn't be done for *every* such font, only for some selection.

The problem is: no matter how we try to show to user that the font there in the list is the *missing* one, it will inevitably be used by inexperienced users as if it were an existing font. Namely, users would format their texts with that font, *and imagine that what they see is what they get* - not realizing that what they see is actually some substitution. And the important thing is: the *quality* of substitution would be completely unpredictable.

So I suggest, if this is to be implemented, to only include those missing fonts, that have either user-defined explicit substitution entries, or built-in substitution rules - like those known metrically compatible pairs. That way, user would see those fonts that are known to provide compatible text layout (built-in case), or at least user-defined substitution tells that the user knows what they do.
Comment 10 ⁨خالد حسني⁩ 2022-12-07 10:54:05 UTC
No other application does this as far as I know and it will likely be a big source of confusion since our replacement fonts are not exact matches (e.g. Callibri now supports Arabic, Carlito doesn't) so there will be differences in layout under certain circumstances and making people think they have a font they don't have will not be helping, font fallback is already confusing to many people.

My suggestion is to close as WONTFIX.