<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Cannot find special character if does not know character name but number" href="https://bugs.documentfoundation.org/show_bug.cgi?id=111816#c7">Comment # 7</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Cannot find special character if does not know character name but number" href="https://bugs.documentfoundation.org/show_bug.cgi?id=111816">bug 111816</a> from <a class="email" href="mailto:vstuart.foote@utsa.edu" title="V Stuart Foote <vstuart.foote@utsa.edu>"> V Stuart Foote</a> <pre>(In reply to Heiko Tietze from <a href="show_bug.cgi?id=111816#c6">comment #6</a>) > (In reply to V Stuart Foote from <a href="show_bug.cgi?id=111816#c5">comment #5</a>) > > 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 (<a class="bz_bug_link bz_status_VERIFIED bz_closed" title="VERIFIED FIXED - add unicode conversion shortcut like word (alt+x)" href="show_bug.cgi?id=73691">bug 73691</a>) and do not integrate OS provided "deadkeys" IME (<a class="bz_bug_link bz_status_NEW " title="NEW - Key combinations to easily insert accented Latin characters" href="show_bug.cgi?id=71176">bug 71176</a> or <a class="bz_bug_link bz_status_NEW " title="NEW - Enable the special MacOS X functionality for special caracter input (éñ etc.)" href="show_bug.cgi?id=42437">bug 42437</a>) 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>