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


I was interested to read your note and have a few thoughts. 

 Environment: MS Win7 64bit Ultimate English with French and Chinese   
language pack, non-Unicode code page: Chinese (CP936), LibreOffice, JRE 1.7.0_09 (both 32-bit and 64-bit). 

Is their any reason you are still using the MS CP936 on your system rather
than Unicode.? You should normally expect the system code settings to equal
or higher than applications otherwise you can have problems for example
cutting and pasting.  LibO is Unicode based
 I note that MS  would also suggest Unicode. 

... Using Unicode is recommended in preference to any code page because it
has better language support and is less ambiguous than any of the code

2. wrong detection of unicode ranges 

A more complicated problem with the Special Character dialog is the   
mis-identification of supported code points in >a font—LO doesn't seem   
to handle this thing correctly at all. Instead, it displays blocks or   
squared question marks >or blanks for the unsupported glyphs in a   
Unicode range partially supported by the font, and glyphs from fallback   
fonts assigned by the OS for a Unicode range the font totally does not   
support—with almost no sign of suppressing >these unsupported glyphs or   
ranges from display. Only very few fonts are correctly identified   
(Cardo, Code2000 >and Quivira, for example). 

There are two issues here, entering text and displaying the text with a
chosen font. LibO does not know what font you may eventually choose to use
to display  some text and therefore follows the Unicode rules as specified
in  The Unicode Standard manual. In my copy of the manual "Unicode Standard
5.0" a useful addition to any college library, deals with this area in a
section called "Unknown and Missing Characters" LibO appears to follow
international standards in this area.

���� (the replacement character) are a different matter and often found when
you cut and paste in windows system when the character sets do not match.

9. wrong font information for mixed language documents

LO Writer failed to display font information correctly for mixed  
language documents. Although a number of glyphs >from non-Latin writing  
systems have been identified and correctly displayed, the font  
information is not set >correspondingly. One example is Ogham. To  
correctly display Ogham glyphs, one need to use fonts like Code2000 >or  
Segoe UI Symbol. However, Times New Roman, a Latin/Greek/Cyrillic/Arabic  
font, is displayed in the “font >name” drop-down or the “character”  
dialog when you select Ogham texts.

When I type Ogham, which is very seldom, I just enter the Unicode directly
(I am using Ubuntu) using the keys.  LibO is set up to substitute for the
missing glyphs. For example, Times New Roman does not contain Ogham but LibO
shows    ᚁᚁᚗᚖᚙ taken from a font with these characters. Whether that is a
good thing has been a subject of discussion.

Anyway good luck. You may find the LibreOffice manuals useful. Either
download the PDFs from the site or to purchase  paper versions from 

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.