<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED INVALID - Insert Special Character arbitrarily restricts which characters in font can be inserted" href="https://bugs.documentfoundation.org/show_bug.cgi?id=112020#c6">Comment # 6</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED INVALID - Insert Special Character arbitrarily restricts which characters in font can be inserted" href="https://bugs.documentfoundation.org/show_bug.cgi?id=112020">bug 112020</a> from <a class="email" href="mailto:khanson679@gmail.com" title="Kenneth Hanson <khanson679@gmail.com>"> Kenneth Hanson</a> <pre>(In reply to Heiko Tietze from <a href="show_bug.cgi?id=112020#c5">comment #5</a>) > Font substitution is another question. We made a suggestion how to improve > this situation at > <a href="https://design.blog.documentfoundation.org/2016/10/21/dealing-with-missing">https://design.blog.documentfoundation.org/2016/10/21/dealing-with-missing</a>- > fonts/ Yes, this wasn't the best example. Glad to see that work is being done on this one, though! > Talking about the special character dialog there is room for advanced > features, no question. While the average user searches by the unicode name > <foo>, your use case is to look for a particular unicode id <U+XYZ> not > knowing in what font it is defined. I think you've written part of this backwards. Searching by name is indeed easier. But KCharSelect can search by name, while LO can't yet. I think both methods are critical with or without a filter by font. By name is for finding a character, by code point is when you already know what you want and want it as quickly as possible. You're right, though, that I want to be able to search by character first, font second. Fonts are too erratic in what symbols they contain, and you don't necessarily know in advance which ones have what you're looking for. > Once we have collected all these > advanced functions we can think about a second view, perhaps a tab or an > expandable area, where those could be added. But for now I believe our > solution is superior to KCharSelect for most users. Right now or in the upcoming 6.0? KCharSelect is indeed unhelpful, since I now understand that it does font substitution without telling you -- that's what caused me to make this erroneous bug report in the first place. But LO is definitely *not* superior yet, because of the missing functionality to search by name. Once it has this much, it will be adequate for the purpose of occasionally inserting symbols.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>