When a document has embedded fonts, I need to be able to see which fonts are getting embedded. AFAICT, there is no UI which lists them; there should be. Given that we currently access this information via File > Proprties, I suppose it makes sense to put the UI there; there's lots of space in the 'Fonts' tab. But I'm not categorically against another option.
+1 Currently we have to export to PDF (and open with a suitable PDF reader) to get an idea of what fonts have actually been embedded into a document. The File -> Properties -> Font panel seems reasonable place to list fonts being embedded, below the check-box controls that perform the action. List should use our same LO string per font as is shown in the a TB Font listbox or the SB Properties deck. Assume it would refresh on actual save to ODF.
(In reply to V Stuart Foote from comment #1) > List should use our same LO string per font as is shown in the a TB Font > listbox or the SB Properties deck. You're (rightly) reminding us of our font family name massaging, where we artificially create pseudo-typefaces in the listbox, because we don't have proper variant support; see bug 35538. Now, in the intended listing of embedded fonts, on the one hand, we have to show embedded font _files_ (as we embed them as files IIANM) - and those might have multiple variants, again IIANM, and at any rate, not present the same string we use as typeface names. There's also the matter of spaces introduced or removed from font family names, which is the subject of bug 143095; I'm not sure that would be a problem here, but it might be.
My thought is for the user to see what we use in the UI in the Font lists, or the Character dialog, but not necessarily what the os/DE font filename might be. For example, compare the fonts as named in the PDF export filter to what we use in the UI and to what the actual font file is named. Sticking to what we present in the UI makes the most sense. If we ever address 35538 we can worry about more correct naming then. For now the core R/B/I/BI of GDI handling, with any OTF features as shown to users across the UI seems to make more sense in our representation of an ODF document archive.