It’s a positive note, that hexadecimal code input with more than four digits works in LibreOffice still since version 5.1. On a less positive note, the hexadecimal code input with more than four digits sometimes works, sometimes not. (See also Bug 103217 – PDF export of Unicode characters…)
I cannot comprehend/reproduce why at the same LO-Writer document (.odt) sometimes a Unicode character (more than four digits) is depicted and sometimes not. If not, then it’s also not possible to generate this Unicode character (or others with more than four digits).
If I save such an LO-Writer document (with non-depicted Unicode characters with more than four digits) in *.docx and open this following in Word 2013 all Unicode characters are correctly depicted.
Please list the code points for some examples from an upper plane, which do not work in LibreOffice, but are shown correctly in Word 2013.
Created attachment 128222 [details]
Document with Unicode characters
Regina, I’m not sure what you mean with „upper plane“ but I list here some examples, which work sometimes in LO-Writer and sometimes not:
U+1D53B MATHEMATICAL DOUBLE-STRUCK CAPITAL D
U+1D54E MATHEMATICAL DOUBLE-STRUCK CAPITAL W
U+1D452 MATHEMATICAL ITALIC SMALL E („Euler’s number“)
I attach also two documents: Characters in Unicode.odt and Characters in Unicode.docx – both created with LO-Writer.
Created attachment 128225 [details]
Document with Unicode charakters
Thanks for the document and examples. The problem is clear now.
When you see a rectangle instead of the character that means, that the selected font has no glyph for the code point. Nevertheless the input method with Alt+x after a U+1nnnn still works.
In my Word 2010 I see the same rectangles with the .docx file as in LibreOffice with the .odt file.
It might be, that Word 2013 has some font substitution. So you need to figure out, which font Word 2013 is actually using and set this font in LibreOffice too.
So I think, this is not really a bug. But it might be an enhancement request, that LibreOffice implements a feature "find a font on my system for this code point", that can be used at least on demand.
Regina, thanks for your detailed comment.
The selected font in the documents – Segoe UI Symbol – has glyph for the code point, and this font was never changed. Sometimes the Unicode character is depicted correctly in LO-Writer, sometimes not – in Word 2013 the Unicode character always is depicted correctly.
Something doesn’t add up and further improvements should be made (See also Bug 103217 – PDF export of Unicode characters…)
I'm no font expert and cannot verify, whether 'Segoe UI Symbol' really has the needed glyphs. So some else has to look, what goes wrong here. Perhaps it matters, whether it is a TrueType (ttf) or OpenType (otf) font?
The GNU freefont "FreeSerif" has got this double strike glyphs. http://ftp.gnu.org/gnu/freefont/. It is part of the .zip file. For my Windows 7 I have chosen the .ttf variant. With that font I see the glyphs.
The name of the „Segoe UI Symbol“-Font is seguisym.ttf from Win 10 Pro (Build 14393). Detailed informations: Version 6.22, OpenType-Layout, digital signed, TrueType contours.
Although this font was (really) installed, I installed it again. Now the Unicode characters with more than four digits are depicted again (but how long?) and the creating of PDF (from LO-Writer) still doesn’t work.
To exclude any possibilities, which could have something to do with the fonts, I did two things:
First, I deleted (over a boot-stick) nearly all fonts (except Arial, Courier New, Microsoft Sans Serif, Symbol, Tahoma and Times New Roman). Afterwards I cleaned the Registry from all false records concerning the deleted fonts with CCleaner. After restart I installed all the fonts which I have separated in a special file, e.g. also all Segoe UI-Fonts (incl. Segoe UI Symbol, Segoe UI Historic and Segoe UI Emoji).
Result: The Unicode characters (with more than four digits) are not depicted in my document (Characters in Unicode.odt) and it’s also not possible to generate Unicode characters (with more than four digits).
Second: I installed „Arial Unicode MS“ (Version 1.01 from 2012/09/29), which is an „extended version of Monotype’s Arial“ and „contains glyphs for all code points within The Unicode Standard, Version 2.1“.
Result: Also if I replace „Segoe UI Symbol“ in my document through „Arial Unicode MS“, the Unicode characters (with more than four digits) are not depicted and it’s also not possible to generate Unicode characters (with more than four digits).
Summary: the hexadecimal code input with more than four digits sometimes works, sometimes not. Yesterday evening it has been worked again, today – after a very clean reinstall of my fonts – it doesn’t work. Something doesn’t add up and further improvements should be made (See also Bug 103217 – PDF export of Unicode characters…).
To exclude any possibilities, I went further, formatted my partition C:\ and made a fully new CleanInstall.
Result: The bug persists.
Issues with font fall back are resolved fixed with target of 5.3.0 with the new HarfBuzz based text layout for bug 89870 set active by default.
If the font is installed on system, the fonts from the SMP (more than 4 bytes) will show a glyph.
Ok, thank you for this good news.