This is valid. But I don't think we should dump it onto Akshay's GSOC 2017 plate.

Would need to toggle the search to be within a single font, or some composite of on system fonts.

For an example of how this could be handled, have a look at Andrew West's work on BableMap [1] where he provides mapping for a Single font or for a Composite font. 

Also provides a "Font Coverage..."  that shows which fonts provide glyph for codepoint.

=-ref-=

[1] http://www.babelstone.co.uk/Software/BabelMap.html

Very unlikely that you know the hex/decimal value but not within what font you find the character. I'd say WF because search is not the same as quick access, i.e. hex/decimal values.

However, the same happens when search is active and I suggested to disable the value fields in this case.

(In reply to Heiko Tietze from comment #2)
> Very unlikely that you know the hex/decimal value but not within what font
> you find the character. I'd say WF because search is not the same as quick
> access, i.e. hex/decimal values.

You can get a code point very easily, not only by searching in the unicode charts but by tools like http://shapecatcher.com/. Of cause you can enter the character name (see below), but that is cumbersome compared with entering the number.

It is likely, that you do _not_ know the font. For example write U+232c and toggle it to unicode. I bet, you get a benzene ring by font fall back. Now tell me which font it is and whether you own other fonts which have this character.

(In reply to Heiko Tietze from comment #2) 
> However, the same happens when search is active and I suggested to disable
> the value fields in this case.

If you have entered the character name correctly and so the search is active, then scrolling the font list works, although the field does not show the correct number. It is good, that this works, so please make no changes, which would disable this feature.

(In reply to Regina Henschel from comment #3)
> (In reply to Heiko Tietze from comment #2) 
> > However, the same happens when search is active and I suggested to disable
> > the value fields in this case.
> 
> If you have entered the character name correctly and so the search is
> active, then scrolling the font list works, although the field does not show
> the correct number. It is good, that this works, so please make no changes,
> which would disable this feature.

Comment to patch 12 at https://gerrit.libreoffice.org/#/c/40563/ ('happens' -> 'happened')

Shapecatcher returns a huge label with the name (where we do offer a outstanding feature) and a tiny unicode value. Only super nerds care about the unicode id primarily.

(In reply to Heiko Tietze from comment #2)
> Very unlikely that you know the hex/decimal value but not within what font
> you find the character. I'd say WF because search is not the same as quick
> access, i.e. hex/decimal values.
> 
> However, the same happens when search is active and I suggested to disable
> the value fields in this case.

@Heiko--I just have to say how ill-considered that statement is--especially as you've already unilaterally had Akshay remove the "Characters:" edit view destroying a functional IME we have had for inputting strings in alternate language scripts. 

And now you are saying that Unicode values are not important for search--and for font selection.  The Special Character dialog _is_ the sames as OS provided quick access--it is _our_ visual interface for providing quick access.

Please give some thought to how we support polyglot users who are very dependent on Unicode and need efficient tools for locating glyphs across font families by Unicode name or Codepoint or Unicode subset.

(In reply to V Stuart Foote from comment #5)
> Please give some thought...

No need to argue, I have no data. You say people remember the unicode id, like it was back in DOS times with ASCII 132 for ä, rather than searching by the name 'umlaut' or the correct term 'DIAERESIS'. 
And I'm not saying it never happens. If I'd use unicode 0x228 for the ä, and wheel through the fonts it should work like with a search term, which is the fact until I reach OpenSymbol. Scrolling now through this font, changes the unicode as expected. 
Turning the use case around, Regina's workflow, the font for a char that is not commonly integrated could be found. That means, when the font doesn't contain of this item nothing is selected in the chars table. But the unicode fields have a value. Today the table corresponds to the id field.
To me the benefits of this workflow don't outweigh the drawback of inconsistency.

(In reply to Heiko Tietze from comment #6)
> (In reply to V Stuart Foote from comment #5)
> > Please give some thought...
> 
> No need to argue, I have no data. You say people remember the unicode id,
> like it was back in DOS times with ASCII 132 for ä, rather than searching by
> the name 'umlaut' or the correct term 'DIAERESIS'. 
> And I'm not saying it never happens. If I'd use unicode 0x228 for the ä, and
> wheel through the fonts it should work like with a search term, which is the
> fact until I reach OpenSymbol. Scrolling now through this font, changes the
> unicode as expected. 

We support folks with our <Alt>+X toggle (bug 73691) and do not integrate OS provided "deadkeys" IME (bug 71176 or bug 42437) so it is a bit disingenuous to suggest now that we don't steer our polyglots toward Unicode. 

> Turning the use case around, Regina's workflow, the font for a char that is
> not commonly integrated could be found. That means, when the font doesn't
> contain of this item nothing is selected in the chars table. But the unicode
> fields have a value. Today the table corresponds to the id field.
> To me the benefits of this workflow don't outweigh the drawback of
> inconsistency.

And the other side of the design case is that we have collapsed empty cells in the Unicode table representation. By doing that we obscure ability to determine the font is missing glyphs/graphemes for Codepoints within a Unicode block.

It makes for concise chart, but destroys one of the strengths of Unicode of being able to select a front from drop list to determine if the font has coverage of the needed glyphs by looking at its table in 15 col hex.

After the GSOC '17 is finished -- I'd move to see the additional support of Unicode based 15 column charts organized/showing HEX value and composite font searches.

> You say people remember the unicode id

For the record, I do remember Unicode code point numbers, because I’m a typesetter and frequently need to insert special characters, which is very easy to do with your keyboard in Linux: Ctrl+Shift+U plus the Unicode number (e.g., 2026 for …). It shows on my LibreOffice UI translations, which at the microtypography level are very polished. I realize I’m a “power user”, but we shouldn’t just design for the lowest-common-denominator use case. To me, it’s sensible that if the Special Characters dialog has a search field, it should allow me to enter a Unicode number and be capable to find the character.

I would assume there are advanced user who do remember unicode numbers, though believe its less likely they don't remember which font its available in, especially if they use them regularly.

Presently we have 3 input field to find a character - the search field for basic users and hex and dec fields for advanced user - and the simplest solution might be to disable input in the hex and dec fields and only have search in the search field. With filtering by hex and dec values in the search field, a user can easily move through the font name list and find which font has that character, similar to how they can do so presently by unicode name.

This remains a valid issue with the Special Character dialog. It need design and dev work.

This remains a valid issue with the Special Character dialog. It needs design and dev work.

Pro tip: set Importance to "enhancement" and voilà, "QA Administrators" will stop nagging )

Well sure, but I'd argue there were multiple implementation issues when the dialog was reworked under GSOC mentorship.

Issue of OP remains, the SMP codepoint value is truncated allowing search only for a BMP glyph.

(In reply to V Stuart Foote from comment #11)
> This remains a valid issue with the Special Character dialog. It need design
> and dev work.

The only reasonable way to search for a code point is to enter it in the search field. Using the hex/dec information of the selected item to search for something would be error-prone and hard to understand. 

We have to detect "U+<number>" and switch the search respectively. No further modification to the UI needed.

I could also imagine a filter for the font list that removes fonts that do not contain the code point or the name entered at search.