Description: There is no apparent logic to which characters appear. For example, choose Liberation Serif or OpenSymbol and navigate to General Punctuation. U+2022 BULLET is available, but the very next character, U+2023 TRIANGULAR BULLET, is not. Which characters appear also seems to depend on the font selected. For example, U+25B3 WHITE UP-POINTING TRIANGLE appears for OpenSymbol but not for Liberation Serif. I confirmed that the above mentioned characters exist in both fonts using a separate program, KCharSelect. I believe there are some other aspects of the Special Character dialog under discussion at the time of writing. Now would be a good time to fix this as well, since it seriously cripples the usefulness of the dialog. Steps to Reproduce: Search for an arbitrary character in an arbitrary font. Actual Results: All characters that exist in the font should be available. Expected Results: Some characters are missing, with no placeholder in the interface. Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Sorry but the fonts indicated actually do not contain glyphs at those codepoints, and LO behavior is correct showing the blank/undefined glyph. Suspect Linux is confusing the issue for you with its fontconfig fallback handling. At 6.0 the Special Character dialog will be dropping the blank/undefined placeholders for the Unicode charts and packing glyphs into the charmap--as now visible glyphs will only be drawn from the droplist selected font. No "composite" of installed fonts, and no rendering as full Unicode charts.
(In reply to V Stuart Foote from comment #1) Wow, this is terrifically confusing. How should I check for problems like this? Put another way, how did you figure it out?
(In reply to Kenneth Hanson from comment #2) > (In reply to V Stuart Foote from comment #1) > > Wow, this is terrifically confusing. How should I check for problems like > this? Put another way, how did you figure it out? Trust LibreOffice :-)
(In reply to Heiko Tietze from comment #3) > (In reply to Kenneth Hanson from comment #2) > > (In reply to V Stuart Foote from comment #1) > > > > Wow, this is terrifically confusing. How should I check for problems like > > this? Put another way, how did you figure it out? > > Trust LibreOffice :-) No, no, seriously. LibreOffice also does font substitution in normal text. But as a user I don't see any way to figure out what it's doing. Case in point: on Ubuntu if I choose "Arial" in the font dialog, LO says "This font has not been installed. The closest available font will be used." But it doesn't tell me what font it's using. In this example I just happen to know that it will be Liberation Sans, but whether because of configuration in LO or in Ubuntu, I have no idea. And in the current case LO wasn't doing font substitution at all.
Font substitution is another question. We made a suggestion how to improve this situation at https://design.blog.documentfoundation.org/2016/10/21/dealing-with-missing-fonts/ 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. 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.
(In reply to Heiko Tietze from comment #5) > Font substitution is another question. We made a suggestion how to improve > this situation at > https://design.blog.documentfoundation.org/2016/10/21/dealing-with-missing- > 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.