Bug Hunting Session
Bug 105318 - Behavior of Special Character dialog on launch when font at edit cursor is not installed and fallback occurs
Summary: Behavior of Special Character dialog on launch when font at edit cursor is no...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
 
Reported: 2017-01-13 23:51 UTC by V Stuart Foote
Modified: 2019-08-05 15:31 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2017-01-13 23:51:22 UTC
Description:
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.

Actual Results:  
Special Character dialog opens with a system font other than the fallback font at edit cursor.

Unable to identify fallback font.

Expected Results:
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.


Reproducible: Always

User Profile Reset: Yes

Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
Comment 1 V Stuart Foote 2017-01-13 23:58:37 UTC
The .FODT sampler attachment 128326 [details] (from bug 103514) is probably a good test document to show this annoyance with the Special Character dialog.
Comment 2 Buovjaga 2017-01-23 15:37:08 UTC
Repro.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.4.0.0.alpha0+
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 3.6.7.2 (Build ID: e183d5b)
Comment 3 Heiko Tietze 2017-02-18 10:47:45 UTC
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.
Comment 4 V Stuart Foote 2017-02-18 14:39:21 UTC
(In reply to Heiko Tietze from comment #3)
> 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.

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.