https://bugs.documentfoundation.org/show_bug.cgi?id=111816
--- Comment #6 from Heiko Tietze <tietze.he...@gmail.com> ---
(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.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
