When font fallback occurs while parsing non-installed fonts, i.e. font is italicized on the the Font list box or the Sidebar Porperties Deck -> Character list box., the Special Character dialog does not use the fall-back font. It uses system font--with Windows 8.1 and 10 that is Segoe UI.
And as we can not otherwise determine what fallback font is used from within LO (currently need to export to PDF and check the embedded font) seems it would be helpful if we could adjust things so that the Special Character dialog gets set to the fallback font in use at edit cursor position.
Showing the in use fallback font with the Special Character dialog could help with several issues:
1. conveniently identify the fallback font substituted
2. permit insertion at edit cursor of glyphs draw from the same fallback font
3. allowing adjustment to the style to use a replacement font that is present
Steps to Reproduce:
Open an ODF document composed with fonts not on system. Observe fallback fonts are in use, i.e. the font list entry for the font is italicized. With edit cursor positioned into the paragraph with the fallback font open the Special Character dialog.
Special Character dialog opens with a system font other than the fallback font at edit cursor.
Unable to identify fallback font.
Some convenient way to identify the fallback font. Special Character dialog should open using the assigned fallback font at edit cursor position. As it does for cursor positioned in font that is present.
User Profile Reset: Yes
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
The .FODT sampler attachment 128326 [details] (from bug 103514) is probably a good test document to show this annoyance with the Special Character dialog.
Arch Linux 64-bit, KDE Plasma 5
Build ID: 63fd4c97118a943c84ba5a666cf8c9cc54b511c7
CPU Threads: 8; OS Version: Linux 4.8; UI Render: default; VCL: kde4;
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on January 22th 2016
Arch Linux 64-bit
Version 126.96.36.199 (Build ID: e183d5b)
Should be solved with https://design.blog.documentfoundation.org/2016/10/21/dealing-with-missing-fonts/. The topic is one of the GSoC'17 ideas, and Akshay seems to be interested. No mentor yet, though.
(In reply to Heiko Tietze from comment #3)
> Should be solved with
> fonts/. The topic is one of the GSoC'17 ideas, and Akshay seems to be
> interested. No mentor yet, though.
Hmm, not quite. Issue is that absent the font (no embed, or not installed to system) the Special Character dialog does not use the fall-back font. Rather it uses the System font.
Otherwise, from edit cursor positions using an installed font, the Special Character dialog opens to that font.
So the Special Character dialog opening to System font is currently inconsistent as is. But--by picking up the fall-back font replacement in use at the edit cursor--the dialog could be made more useful and less inconsistent.
That would be regardless of the UI work that the design blog/GSoC'17 might address.
Please add keyword 'needsUXEval' and CC 'firstname.lastname@example.org' if input from UX is needed.
Then it disappears again. I don't want these stupid workarounds like floating boxes everywhere.
See also this question/community bug report here: