Bug 94327 - UI: Apply font substitutions for global replacement of missing (or incorrect) font names
Summary: UI: Apply font substitutions for global replacement of missing (or incorrect)...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL: https://design.blog.documentfoundatio...
Whiteboard:
Keywords:
: 95097 (view as bug list)
Depends on:
Blocks: Options-Dialog Fonts Font-Substitution
  Show dependency treegraph
 
Reported: 2015-09-17 20:21 UTC by tmacalp
Modified: 2020-10-26 13:13 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Mockup for a new font substitution page (47.68 KB, image/png)
2016-07-27 11:32 UTC, Heiko Tietze
Details
Mockup for alert message (153.22 KB, image/png)
2016-07-29 20:43 UTC, Shunesburg69
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tmacalp 2015-09-17 20:21:28 UTC
It would be very useful to have a way to replace all existing missing fonts with their substitutions.

We've been using StarOffice, OpenOffice, and LibreOffice for many years.  Many of our documents were created years ago and have been moved to new systems with different names for similar fonts.  As a result, most of our documents look fine, but suffer from font substitution issues.

Manually fixing these missing fonts can be quite arduous, since the fonts can be found anywhere in these documents, from styles to direct formatting changes to character, paragraph, etc...

I'm not too sure how best to implement such a feature.  At its most simple, it could be a simple button, hidden under the File -> Properties -> Font tab.  On the more complicated side, it would also be nice to at least see a list of all fonts currently being substituted and all of the replacements.  

The best implementation I can think of would be to modify the existing font replacement table (Tools->Options->LibreOffice->Fonts) so that it also shows the current active font substitutions in your current document.  It would need some way to differentiate the normal global font replacements and the current document replacements.  It could possibly show the actively substituted fonts as bold and allow you to right click the font to apply the replacement and offer an "apply all" button.  This implementation has the benefit of clearly showing a user all of the missing fonts in their document.  It also could give the user a way to quickly set common global font replacements that they might run into in other documents.
Comment 1 Buovjaga 2015-10-01 10:51:11 UTC
Let's ask UX.
Comment 2 Shunesburg69 2015-10-15 20:18:24 UTC
What is this UX ?

I have made a proposition in the "Crazy Ideas"
https://wiki.documentfoundation.org/Development/Crazy_Ideas#Missing_Font_Manager

I hope one day, it will be take in charge.
Comment 3 V Stuart Foote 2015-10-15 20:53:18 UTC
Reasonable. And I think @shunesburg69 hit the correct tone for the enhancement in his "Crazy Idea" Wiki entry. To NEW and back to UI.

=-=-=
Q. 
What is this UX?

A.
UX is a notation for "User eXperience", within the LibreOffice project it is often used as a shorthand for the "Design & UX" team. Applicable issues are routed for design (UI & functional) review by assigning/reassigning a bug to the ux-advise component--which routes the issues to subscribers to The Document Foundation -- Design mailing list.

ux-advise notated bugs get a slightly different QA triage, and often will be flipped back to the specific LO component with comments as I'm doing here.
Comment 4 Tomaz Vajngerl 2015-10-15 21:02:35 UTC
*** Bug 95097 has been marked as a duplicate of this bug. ***
Comment 5 Tomaz Vajngerl 2015-10-15 21:06:25 UTC
As I already said in that duplicate. "Crazy Ideas" wiki page is for CRAZY IDEAS - that by definition will most likely never be implemented. I wouldn't encourage people to write their ideas into that wiki page.
Comment 6 Shunesburg69 2015-10-15 21:15:57 UTC
Crazy not meaning never implemented but just too ambitious to be implemented now.
Comment 7 Heiko Tietze 2016-07-27 11:32:13 UTC
Created attachment 126432 [details]
Mockup for a new font substitution page

Here is a not so crazy mockup, hopefully.

I tried to combine all fonts into one table to not clutter the dialog with controls. It has now an additional column "Global" which is unchecked when the font substitution comes from the document. In case it has no replacement the respective column would be blank.

Checking this option makes the substitution global meaning it is applied even after the document was closed. The user can change this option until the document is closed (therefore the lower checkmarks are disabled).

The mockup changes the current behavior with external controls and provides inline editing. Also a WYSIWYG comparison as suggested by Shunesburg69 would be nice (the preview column with icons that open a rich tooltip/floating frame). The 'Add' button inserts another row; it is not really necessary as user may advance after the last row.

I'm not entirely happy with the mockup. The checkbox is not the right control to "move" items from one list (document substitution) to another list, and always disabling them makes also not much sense. However, the interaction is more or less clear to the user. But what I also dislike is the presumption that users know what the opposite to checking an option is (not 'global' means it is a document font; 'always' means to have it either substituted even when the font is installed, screen only is obvious).

I wonder if checking 'Screen only' makes sense when Always is checked.

And finally there was a discussion how to show substituted fonts in the dropdown (in italic). Don't remember the details but it would be nice to have a similar visualization on places with the same information. Icons are a good cue for that.
Comment 8 Shunesburg69 2016-07-29 20:43:15 UTC
Created attachment 126477 [details]
Mockup for alert message
Comment 9 Heiko Tietze 2016-07-29 22:08:02 UTC
(In reply to shunesburg69 from comment #8)
> Created attachment 126477 [details]
> Mockup for alert message

Isn't this control, called 'info panel' in LibO, a little bit too much warning? And actually the info panel is usually not interactive.

But of course we need better information (talked about the issue today in the UX meeting).
Comment 10 Shunesburg69 2016-10-11 22:03:51 UTC Comment hidden (obsolete)
Comment 11 V Stuart Foote 2016-10-11 22:41:06 UTC
(In reply to shunesburg69 from comment #10)
> Why too much, if it's necessary ?
> I don't know if there are too much warnings but this one is important.

Too much as in overdone, excessive, garish, obnoxious and just plain annoying. =D

Otherwise the enhancement requested here is to be able to reliably modify the ODF documents to change the styles and direct formatting (held styles.xml & content.xml respectively). So that on reopening the styles and direct formatting are annotated with desired fonts.

Enhancing the Font dialog to optionally show the fallback font replacement done during filter import of a document would be helpful, in addition to the current font replacement table. 

Also helpful, would be adding options for the export filters to modify the Style and Content xml--effectively updating the document with the font replacements being made (either fallback or the font replacement table).

Finally think it would be useful if the Font dialog indicated if a font was subset/embedded into the document and--when font replacement occurs or is forced--allow removal of the embedded font, and optionally its replacement on export back to ODF. Effectively "re-styling" the document.
Comment 12 Heiko Tietze 2020-07-28 09:03:36 UTC
Besides the notification we have a proper mockup for the enhancement. Removing UX so developers can take it.
Comment 13 Timur 2020-10-21 12:11:39 UTC
I may not understand this request, but we already have bug 64509 and Comment 0 seemed like a duplicate. 
There is explained that in Linux it's primarily Fontconfig that should deal with fonts, but if it doesn't, I think LO table should be pre-filled for all common commercial or old fonts, at least those from my attachment 166544 [details].
Also wanted and useful is bug 61134 and bug 108243.

Solution in Comment 7 focuses this bug on new "global" option, if I understand it. Again, I don't see the point in having it, if current replacement table works. 
Bug 43185 and example attachment 166579 [details] show that replacement doesn't work well. 
I'd rather have another check "enabled" so that one may turn off replacement without deleting it.

Comment 8 alert - there's bug 78186 and bug 96872.

So please read this comment and explain the purpose of this bug.
Comment 14 V Stuart Foote 2020-10-21 15:07:31 UTC
(In reply to Timur from comment #13)
> I may not understand this request, but we already have bug 64509 and Comment
> 0 seemed like a duplicate. 
> ...

> So please read this comment and explain the purpose of this bug.

No they are not duplicate enhancements. 

This bug addresses mechanism to bypass the font fallback and to globally modify font names filter imported from existing document, or document template(s)--effectively changing the font/font-name strings for style/content XML when filter exported to ODF.

bug 64509 covers the "simple" automated os/DE font fallback handling: Linux by fontconfig, macOS by CoreText, or on Windows as pulled from VCL.xcu applied to an ODF archive on filter import. 

With modification in the VCL.xcu by locale to the font 'defaults' per module as well as the fallback font sequence applied when applicable (i.e. not provided by os/DE).

Heiko provided GUI mockup of using the Tools -> Options -> Fonts 'Replacement Table' to perform the replacements, which seems fine for authoring or modifying. But I could see this requirement solved as a standalone Tools dialog. Helpful as the workflow would be one-off conversion/global font replacement.
Comment 15 V Stuart Foote 2020-10-23 16:05:21 UTC
@Heiko, should the Google docs notes, mockup revisions, and comments [1] from 2016 be curated lest they go missing?

=-ref-=
[1] https://docs.google.com/document/d/1mbs-NW_w8lczMyMwUl5Uc0GYuhFK_KE6g7NASZBnIM0
Comment 16 Heiko Tietze 2020-10-26 13:13:44 UTC
(In reply to V Stuart Foote from comment #15)
> @Heiko, should the Google docs notes, mockup revisions, and comments [1]
> from 2016 be curated lest they go missing?

Done with https://nextcloud.documentfoundation.org/s/H3A2jHyDmBdxc7a