Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index

Frank, *

CVAlkan wrote
I, for one, am totally opposed to any perpetuation of this absurd
distinction between "typing" and "unicode" as it only perpetuates the
silly idea that somehow western character sets are "normal" and other
scripts are "complex text". Are Arabic, Japanese, Hebrew, Hindi, Korean,
Laotian and Thai-speaking users not "typing" simply because they use a
different alphabet? 

Thank you, well put!


Having said all that, Writer certainly could use some UI elements that
could help: an indication as to what font is actually being used at any
given time (and no: the displayed font is NOT always the one in use even
when single non-Latin glyphs are used); an indication as to what Unicode
plane a character is in, and so forth. Some of the poster's suggestions
would certainly be welcome. The ability to pick a font based on the
unicode ranges desired would be wonderful - but it strikes me that this
really isn't the responsibility of an application ...  Being able to
select a font and be able to determine which planes are implemented might
be more practical, although there are many fonts which "support" a given
plane without including all of its defined glyphs. It's a tough call by
any measure.

Which raises the question, where in the LibreOffice GUI would this belong? 
IMEs (like iBUS) are implemented in the OS, but at the application level
within LibreOffice more remains to be done.  

As you've noted on multiple occasions the CJK and CTL "modes" in LibreOffice
still need considerable attention ( tdf#96255
<>  ). 

As LibreOffice has now implemented the :Emoji: auto-correct glyph
replacements, and the <Alt>+x Unicode toggle, we now exposed a lot of users
to use of glyphs contained in the Unicode SMP--which the default typeface
for the script in use is often not covered--nor in an often broken
fallback--resulting in some interesting visual glitches during editing.
Also, integral to LibreOffice, we need to examine the Unicode page
maps--searching by codepoint names or even graphic composition of glyphs
which requires efficient extraction of coverage.  

All of which lands us back on LibreOffices GUI for Special Characters. A UI
element already consistent across script in use, but which is lacking some
essential features for better composition of multi-script text. 
Specifically for managing the tables of Unicode codepoints, and search for
and display of typeface coverage of those tables.

A number of suggested enhancements to the Special Character dialog have
already been implemented

But there is much more that could be done to enhance the Special Character
dialog as an application component of LibreOffice for multi-script Unicode
beyond the core handling in "Western", CJK and CTL scripts  that admittedly
need developer attention.  

But, frankly this discussion does not belong on the User list--rather with
the Design and UX-Advise channel.


View this message in context:
Sent from the Users mailing list archive at

To unsubscribe e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.