Half of this is a "fuzzy" report. I just had a user trying to use the font replacement dialog and failing to get any result. What to expect from the state of the checkboxes in that table is really hard to understand, IMHO impossible without the help page. I'm not sure this can be simplified. The whole workflow seems strange: You have to enable the checkbox "apply font replacement table" to actually edit the table. But that checkbox is beneath it. Currently that checkboy enables the buttons and the table, but disabling the checkbox doesn't disable the buttons (just a minor error). And the font combo boxes are always enabled. IMHO the fixes needed are: 1. Consistently dis- and enable all the controls involved 2. Move the checkbox above the table I will push a patch for that to Gerrit as an initial fix. But then I propose that the UX people have a look at it and eventually we can come up with some good ideas to make the usage more clear with a better workflow.
+1
Another facet needing attention with the Font Replacment Table dialog is what happens with Graphite or OpenType 'smart font' features. Both that they are enabled, but also as passed into a replacement font.
While writing my patch I found more problems. - if I call toString() on an empty OUStringBuffer, LO crashes Thread 1 "soffice.bin" received signal SIGSEGV, Segmentation fault. 0x00007ffff7f333a9 in rtl_uString_newFromStr_WithLength (ppThis=0x7fffff7ff0a0, pCharStr=0x55555ac25018 u"", nLen=0) at sal/rtl/strtmpl.cxx:1367 1367 { (gdb) bt 10 #0 0x00007ffff7f333a9 in rtl_uString_newFromStr_WithLength (ppThis=0x7fffff7ff0a0, pCharStr=0x55555ac25018 u"", nLen=0) at sal/rtl/strtmpl.cxx:1367 #1 0x00007ffff376cb3a in rtl::OUString::OUString (length=<optimized out>, value=<optimized out>, this=0x7fffff7ff0a0) at include/rtl/ustring.hxx:289 #2 rtl::OUStringBuffer::toString (this=<optimized out>) at include/rtl/ustrbuf.hxx:541 #3 Edit::GetText (this=<optimized out>) at vcl/source/control/edit.cxx:2580 #4 0x00007ffff376cb00 in Edit::GetText (this=<optimized out>) at vcl/source/control/edit.cxx:2578 #5 0x00007ffff3a4a575 in SalInstanceComboBoxWithEdit::get_active_text (this=<optimized out>) at vcl/source/app/salvtables.cxx:6125 #6 0x00007fffa7be5cba in SvxFontSubstTabPage::SelectHdl (this=this@entry=0x55555c054660, pWin=0x55555c008fb8) at cui/source/options/fontsubs.cxx:336 #7 0x00007fffa7be58a8 in SvxFontSubstTabPage::CheckEnable (this=this@entry=0x55555c054660) at cui/source/options/fontsubs.cxx:396 #8 0x00007fffa7be5c00 in SvxFontSubstTabPage::SelectHdl (this=this@entry=0x55555c054660, pWin=0x55555c008fb8) at cui/source/options/fontsubs.cxx:349 #9 0x00007fffa7be58a8 in SvxFontSubstTabPage::CheckEnable (this=this@entry=0x55555c054660) at cui/source/options/fontsubs.cxx:396 I think OUStringBuffer::toString should work with empty strings. - if I select a line, the first checkbox is toggled on every click (tdf#138865) - the delete button always refers to the selection and has nothing to do with that line - you can add multiple substitution for the same font, which is a unexpected - selecting multiple entries fills the combo boxes with the first selection Some of this happens, because tdf#136534 didn't fix all of the wrong text lookups. Proposed patch: https://gerrit.libreoffice.org/c/core/+/107642
(In reply to V Stuart Foote from comment #2) > Another facet needing attention with the Font Replacment Table dialog is > what happens with Graphite or OpenType 'smart font' features. Both that they > are enabled, but also as passed into a replacement font. Stuart, could you rephrase that? I don't understand what's the point with Graphite and OpenType fonts wrt the replacement table.
(In reply to Jean-Francois Nifenecker from comment #4) > (In reply to V Stuart Foote from comment #2) > > Another facet needing attention with the Font Replacment Table dialog is > > what happens with Graphite or OpenType 'smart font' features. Both that they > > are enabled, but also as passed into a replacement font. > > Stuart, could you rephrase that? I don't understand what's the point with > Graphite and OpenType fonts wrt the replacement table. If font features are enabled (via the Graphite appended tag mechanism) are they passed through to the replacement font? And what happens when the replacement font has no support for a particular smart font feature? Likewise, for the target font and replacement, should there be a difference between the core font and a font with its features enabled. IIUC currently we only handle the core font as target and as replacement. For example a text run in Writer in Time New Roman with Small Caps set with :smcp flag. The flag can be added to the listbox entry for the target font, but then the font will not be found. While a replacement of Time New Roman with :smcp set with Biolinum G will keep the :smcp feature formatting. But replacement with Liberation Serif will not. But this is an aside to what Jan-Marek is poking at here regards the GUI, with the enabling check box being below the font target and replacement table. And what difference between the apply 'Always' and 'Screen only' checkboxes.
Thanks a lot Stuart. I get the points.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/579cf9548615e8535a0569a8eb4cdf325fbbbac7 tdf#138857 fix font replacement table GUI It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/c4fb3b2a36ae044906b79012a33ee43ec989778a tdf#138857 fix font replacement table GUI It will be available in 7.1.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Commit Notification from comment #8) > Jan-Marek Glogowski committed a patch related to this issue. Fixed, I guess.
(In reply to Heiko Tietze from comment #9) > (In reply to Commit Notification from comment #8) > > Jan-Marek Glogowski committed a patch related to this issue. > > Fixed, I guess. (In reply to Jan-Marek Glogowski from comment #0) > Half of this is a "fuzzy" report. > > IMHO the fixes needed are: > 1. Consistently dis- and enable all the controls involved > 2. Move the checkbox above the table I've fixed this, the obvious bugs. > But then I propose that the UX people have a look at it and eventually we > can come up with some good ideas to make the usage more clear with a better > workflow. Nothing was done for UX. If you think there is nothing else to do, you can close it again. Or we open a new bug?
(In reply to Jan-Marek Glogowski from comment #10) > Or we open a new bug? There are plenty, thought none about shuffling controls around ;-). bug 78186 Add an easy way to know which fonts are used in a document and which of them are missing bug 94327 UI: Apply font substitutions for global replacement of missing (or incorrect) font names bug 96872 Make it more obvious that a font has been substituted (see comment 12) bug 104667 Font substitution mechanism for import formats https://design.blog.documentfoundation.org/2016/10/21/dealing-with-missing-fonts/ https://design.blog.documentfoundation.org/2018/02/18/improvements-font-listing/