Issue 96826 - Add font autoinstallation support
Summary: Add font autoinstallation support
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 3.0
Hardware: Unknown Unix, all
: P3 Trivial with 2 votes (vote)
Target Milestone: AOO Later
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Blocks: 97765
  Show dependency tree
Reported: 2008-12-03 08:35 UTC by nmailhot
Modified: 2017-05-20 11:33 UTC (History)
5 users (show)

See Also:
Issue Type: FEATURE
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description nmailhot 2008-12-03 08:35:00 UTC
The Linux platform is gaining an on-demand font autoinstallation framework (BSD
and Solaris will probably follow eventually). should be plugged into it and use it to request the fonts its
documents need. This would have a huge user impact, especially writer-side
Comment 1 2009-01-15 09:08:40 UTC
confirmed. I guess thats a task for framework.
Comment 2 caolanm 2009-04-03 12:03:45 UTC
We might be able to support the "language" based stuff similarly to what pango
does, i.e. in our final fontconfig-using glyph fallback code collect the total
failures and catalogue them by language or sommat like that and on a timer make
the dbus call to flush pending "missing languages".

Like the wiki page says, asking for a specific font to be installed because its
missing is tricky given the way fontconfig works makes it hard to know when a
font family or "good" replcement font is not really available
Comment 3 nmailhot 2009-04-03 12:23:13 UTC
I think that OO.o is a big enough font users the people working on font
installations would be delighted to know its exact requirements to perfect
auto-installation. If it works for OO.o it will probably work for everyone else.
Comment 4 2009-04-06 11:33:49 UTC
Fontconfig already gets asked how a font should be substituted ("font fallback"). Fontconfig also gets 
asked when codepoints are not supported by a font ("glyph fallback").

Other apps also go via fontconfig, so it has a pretty good picture of what is going on: which fonts are 
available, which fonts are requested, which codepoints/languages need more support and in which font 
contexts these languages are used.

So I think the best approach would be that fontconfig makes a list of suggestions first. The next step is to 
either broadcast the suggestions directly to AFI or have OOo poll the suggestions once in a while and 
broadcast them.
Comment 5 thorsten.martens 2009-10-05 09:50:44 UTC
TM->HDU: please take over or reassign to the appropiate developer. Thanks in
Comment 6 2009-10-15 12:31:07 UTC
To be done when fontconfig support for that becomes available
Comment 7 nmailhot 2009-10-15 13:02:41 UTC
This is a funny argument, the mechanism was coded by the upstream fontconfig
maintainer, and lead to the creation of new fontconfig commands. He'd be very
surprised to learn he had ignored fontconfig aspects while doing so.

IIRC this is one of the bits that justified the fontconfig 2.7 major release
Comment 8 2009-10-15 13:34:04 UTC
Good to know as it is not very obvious from the fc27 release announcement:

Looking at the new APIs it is still not clear to me: how does an app decide when the substitution font 
suggested by fontconfig is not good enough so it should request AutoFontsAndMimeInstaller to search for 
other fonts and install them? Example: "Segoe" is not available but "Frutiger" is. FC suggests the latter as a 
fallback. Should OOo use "Frutiger" or should it ask AutoFontsAndMimeInstaller to search the internet for 
Comment 9 caolanm 2009-10-15 13:51:15 UTC
Earlier (I haven't read any recent docs) on the first version of this support
was that only to search when there is a failure on *glyph* substitution to
return a usable font. i.e. take the returned fontnames on faith, e.g. Liberation
Serif for Times New Roman or whatever, but if there isn't any installed coverage
for a script then fire it off to search for some font that can display the text.
Comment 10 nmailhot 2009-10-15 14:10:21 UTC
IIRC (I may be wrong) part of the decision for GNOME apps happens at pango-level

Now OO.o has a much heavier font use that your average app, and I wouldn't be
surprised that investigating auto-font-installer support for OO.o resulted in a
set of RFEs for the current auto-font-installer. But that will only happen if
OO.o people look at the initial implementation and identify areas that need
improvement (however even limited support at first is better than no support at all)
Comment 11 2009-10-15 14:42:04 UTC
Ok, doing it as a last level resort for glyph fallback looks like a reasonable first step. The resulting 
modal dialog may be annoying though e.g. when something with an invalid encoding is pasted 
resulting in gazillions of weird codepoints.

Regarding RFEs for this feature I already have an idea: make FC interact with AFAMI directly. If an app 
asks for a font with support for a specific codepoint and FC does not find a good answer, it should ask 
AFAMI for help. IMHO it should be configurable whether FC does this asynchronously, synchronously 
(using a modal) dialog or if the feature is disabled, globally or application specific or as part of the font 
pattern. OOo already does the right thing when the equivalent of a WM_FONTCHANGED comes along.

I would prefer it to be asynchronous by default. And having a patterns like FC_AUTOFONT_REQUIRED, 
distinguish important use cases such as idle formating or UI-text.

IMHO most external observers overestimate the number of "OO.o people" working on stuff like this...
Comment 12 caolanm 2009-10-15 14:50:25 UTC
a) "resulting in gazillions of weird codepoints.", yup. get it with accidental
binary goo in gnome-terminal

b) "overestimate the number of OO.o people", yup, I'd hoped to pick up this
myself by F-12, I might try again to do this myself by F-13
Comment 13 2009-10-15 15:07:00 UTC
> I'd hoped to pick up this myself by F-12, I might try again to do this myself by F-13

Thanks! I still think you should concentrate on a FC<->AFAMI interaction and then making sure that apps 
such OOo gets notified when they succeeded in installing new fonts. OOo will happily reformat then.

Having FC negotiate with AFAMI would have so many benefits... as I already said in #desc5 FC has the full 
picture of what is going on, what is missing etc. And as a central configuration entity for font-related 
questions it will better know the relationships between different fonts, where to get them directly, where 
to get nice substitutions. Managing the font autoinstallation from a module other than FC just calls for 
trouble, useless extra work, annoying modal dialogs, etc.
Comment 14 Marcus 2017-05-20 11:33:48 UTC
Reset assigne to the default "".