confirmed. I guess thats a task for framework.

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

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.

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.

TM->HDU: please take over or reassign to the appropiate developer. Thanks in
advance.

To be done when fontconfig support for that becomes available

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

Good to know as it is not very obvious from the fc27 release announcement: 
http://lists.freedesktop.org/archives/fontconfig/2009-June/003177.html

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 
"Segoe"?

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.

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)

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, 
FC_AUTOFONT_SUGGESTED, FC_AUTOFONT_MAYBE or FC_AUTOFONT_DONTCARE would help to 
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...

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

> 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.

Reset assigne to the default "issues@openoffice.apache.org".