Description: Font fallback and Glyph fallback mechanisms bring in ambiguity in fonts used to display a document and PDFs created from a document. One one hand, it solves problem of substituting fonts and glyphs which is very useful in a lot of use cases (especially when user don't care about the font), but on the other hand it irreversibly hides control under this behaviour from experienced users where user needs to have control under the fonts used in document. When Writer used for publishing purposes it is very important to have control under fonts used in result documents to eliminate situations of appearing prorpietary fonts from the result PDF, as maker-up dont have any information about absent glyphs and fonts until the moment of making result PDF. And even after it is a terrible journey to find substituded glyphs. As far as I know command line variable SAL_DISABLE_FC_SUBST to turn off font fallback was removed in 5.4 I think this is a regression. Actual Results: Forced font substitution by Font fallback and Glyph fallback Expected Results: Option not to use font fallback and glyph fallback. Like SAL_DISABLE_FC_SUBST variable. Reproducible: Always User Profile Reset: No Additional Info:
I could not find the commit killing off ability to disable font fallback to put it in context. But looks like SAL_DISABLE_FC_SUBST was a crutch added for support of Solaris [1][2] and was overtaken by events in refactoring SAL_LAYOUT and implementing HarfBuzz cross-platform. To my mind, a properly functioning fontconfig with font subsetting into ODF or exported PDF is the preferred usage. But that is no substitute for users correctly appling style based font selection with full coverage in preparing documents. IMHO => NAB =-ref-= [1] https://bz.apache.org/ooo/show_bug.cgi?id=96317 [2] https://bz.apache.org/ooo/show_bug.cgi?id=85483
> To my mind, a properly functioning fontconfig with font subsetting into ODF > or exported PDF is the preferred usage. But that is no substitute for users > correctly appling style based font selection with full coverage in preparing > documents. Users can get information about font fallbacks to fix them, but AFAIK there is no way to get information about glyph fallbacks. IMHO Glyph fallbacks shouldn't be invisible for users and removal of workaround for this behaviour is a regression bug, isn't it?
IIUC identifying the actual font used for missing glyph(s) fallback (i.e. no Unicode coverage) is managed by the os/DE in use, i.e. fontconfig on Linux, which actually makes the font selection for missing glyphs/fonts based on configuration. LibreOffice's UI handling of replacement fonts and fallback is related but already open: see bug 61134, bug 94327, bug 96872 Only question there is if the UI is made sufficiently granular to handle single codepoint fallback, e.g. maybe provide a Find & Replace dialog mode for glyph fallback. Disabling glyph fallback substitution--and so showing an installed/assigned fonts' "undefined" placeholder glyph on LO document canvas--is a legitimate approach to handling glyph fallback. It was tangentially provided but has now been removed by dropping "SAL_DISABLE_FC_SUBST" control. The general user preference will be for glyph fallbak as provided by os/DE, IMHO don't see much demand to override that as IIUC it is not possible to implement cross platform. But I'd like to hear dev perspective on that.
(In reply to V Stuart Foote from comment #1) > I could not find the commit killing off ability to disable font fallback to > put it in context. But looks like SAL_DISABLE_FC_SUBST was a crutch added > for support of Solaris [1][2] and was overtaken by events in refactoring > SAL_LAYOUT and implementing HarfBuzz cross-platform. It was dropped in ff8a29d01afef082741871c7ac40f635a5e2bfad, no relation to HarfBuzz.
(In reply to Khaled Hosny from comment #4) > It was dropped in ff8a29d01afef082741871c7ac40f635a5e2bfad, no relation to > HarfBuzz. @Khaled, thanks! My cgit-fu was weak... Anyhow, can you envision some means to enable a mode to provide glyph/grapheme level identification when os/DE font fallback occurs with mixed fonts? In bug 105318 I'd suggested using the Special Character dialog to respond by displaying the font fallback used at cursor position--rather than the system UI default--as a means of identifying glyph/grapheme specific fallback. But not sure that is even possible.
(In reply to Khaled Hosny from comment #4) > (In reply to V Stuart Foote from comment #1) > > I could not find the commit killing off ability to disable font fallback to > > put it in context. But looks like SAL_DISABLE_FC_SUBST was a crutch added > > for support of Solaris [1][2] and was overtaken by events in refactoring > > SAL_LAYOUT and implementing HarfBuzz cross-platform. > > It was dropped in ff8a29d01afef082741871c7ac40f635a5e2bfad, no relation to > HarfBuzz. What was the purpose of this removal?
(In reply to V Stuart Foote from comment #5) > (In reply to Khaled Hosny from comment #4) > > It was dropped in ff8a29d01afef082741871c7ac40f635a5e2bfad, no relation to > > HarfBuzz. > > @Khaled, thanks! My cgit-fu was weak... Anyhow, can you envision some means > to enable a mode to provide glyph/grapheme level identification when os/DE > font fallback occurs with mixed fonts? We would want to tag glyph items that came from a fallback font (not that hard), and communicate that information all the way up to the UI layer (not my area of expertise).
(In reply to Georgy from comment #6) > (In reply to Khaled Hosny from comment #4) > > (In reply to V Stuart Foote from comment #1) > > > I could not find the commit killing off ability to disable font fallback to > > > put it in context. But looks like SAL_DISABLE_FC_SUBST was a crutch added > > > for support of Solaris [1][2] and was overtaken by events in refactoring > > > SAL_LAYOUT and implementing HarfBuzz cross-platform. > > > > It was dropped in ff8a29d01afef082741871c7ac40f635a5e2bfad, no relation to > > HarfBuzz. > > What was the purpose of this removal? Code cleanup. It was an undocumented feature that degraded the user experience when active (it did not disable font fallback, it disabled using FontConfig for it).
Georgy, nothing happened to this unconfirmed bug report for six month. Khaled gave some explanations in comment 7 and comment 8. So please give a short information about what should still be done. => NEEDINFO
Dear Georgy, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
I still think that there should be an option to turn off font fallback and glyph fallback.
[Automated Action] NeedInfo-To-Unconfirmed
Think we should resolve this request as WF. Khaled explained why it was removed and Stuart pointed out that glyph fallback is up to the OS/DE.