Bug Hunting Session
Bug 91155 - Special characters dialog, glyphs for Unicode characters above U+FFFF not rendering
Summary: Special characters dialog, glyphs for Unicode characters above U+FFFF not ren...
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
4.4.3.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: regression
Depends on:
Blocks: Font-Rendering
  Show dependency treegraph
 
Reported: 2015-05-08 08:01 UTC by yuntsia
Modified: 2015-09-07 19:58 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
screen clip U+1D550 (83.13 KB, image/png)
2015-05-08 20:41 UTC, V Stuart Foote
Details
Character rendering of U+1D550 in Writer document and "Special Character" dialog in Windows 8. (163.67 KB, image/png)
2015-05-09 08:28 UTC, yuntsia
Details
Character rendering of U+1D550 in Writer document and "Special Character" dialog in Windows 7. (319.00 KB, image/png)
2015-05-09 08:29 UTC, yuntsia
Details

Note You need to log in before you can comment on or make changes to this bug.
Description yuntsia 2015-05-08 08:01:39 UTC
I'm using Windows 7 x64 and LibreOffice 4.4.3.2.

In LibreOffice 4.4.3.2, any Unicode character of U+10000 or beyond is not showing correctly: instead of showing the character, a rectangle or a space is shown.

In dialog “Special Character”, character of U+10000 or beyond is not shown. (A font supporting that range is selected.)
Comment 1 yuntsia 2015-05-08 10:04:32 UTC
I tried LibreOffice Still (4.3.7.2) in Windows 7 x64, the same problem occurs.
Comment 2 V Stuart Foote 2015-05-08 20:41:04 UTC
Created attachment 115460 [details]
screen clip U+1D550

So as can be seen in attached screen clip an example glpyh U+1D550 (U+120144) with "Linux Libertine Display G" displays just fine. Also on Windows with 4.4.3.2

That said, a lot of the fonts simply do not include glyphs beyond U+FFFF/65536.

What font are you looking at?
Comment 3 yuntsia 2015-05-09 08:28:45 UTC
Created attachment 115466 [details]
Character rendering of U+1D550 in Writer document and "Special Character" dialog in Windows 8.
Comment 4 yuntsia 2015-05-09 08:29:47 UTC
Created attachment 115467 [details]
Character rendering of U+1D550 in Writer document and "Special Character" dialog in Windows 7.
Comment 5 yuntsia 2015-05-09 08:39:26 UTC
(In reply to V Stuart Foote from comment #2)
> Created attachment 115460 [details]
> screen clip U+1D550
> 
> So as can be seen in attached screen clip an example glpyh U+1D550
> (U+120144) with "Linux Libertine Display G" displays just fine. Also on
> Windows with 4.4.3.2
> 
> That said, a lot of the fonts simply do not include glyphs beyond
> U+FFFF/65536.
> 
> What font are you looking at?

After seeing your screencapture, I tried 4.4.3.2 + Windows 8 x64, everything is just fine! Problem seems to only occur in Windows 7. Screencaptures are given as attachments.
Comment 6 yuntsia 2015-05-09 09:00:19 UTC
(In reply to V Stuart Foote from comment #2)
> What font are you looking at?

Linux Libertine Display G, the same as yours.
Comment 7 V Stuart Foote 2015-05-09 14:54:54 UTC
I am on Windows 7 sp1, 64 bit en-US with
Version: 4.4.3.2
Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16
Locale: en_US

So it is not likely an issue between Windows 7 and Windows 8.

Any possibility that some other program on you Windows 7 system had deployed Linux Libertine Display, or other Graphite fonts?

Also, attachment 115467 [details] from Windows 7 is rather odd, that looks to be a substitute font. I dpn't think the LibreOffice distributed Linux Libertine Display Graphite foundry includes glyphs for the Half-width and Full-width form subset.  The LibreOffice deployed Linux Biolinum Graphite font does, but displays "placeholder" for missing glyphs. Not sure why that is, maybe someone can explain it.

Maybe a better uni-code character to track across the font foundries would be the US cent U+00A2 and its U+FFEO from the Half-width and Full-width form. As well as the UK pound U+00A3 and its U+FFE1 -- comparing the character style from the Latin-1 and the Half-width/Full-width subsets should help decide if glyphs are from the same foundry.
Comment 8 Khaled Hosny 2015-05-09 15:09:44 UTC
I’m not sure what is the issue here (or why I’m CC'd), the last comment is especially very gibberish to me. Can someone spell out clearly what LibreOffice/OS/font combination work and what does not?
Comment 9 V Stuart Foote 2015-05-09 15:37:44 UTC
@Khaled, sorry added you to the cc before simply adding to the bug 71732 meta.

Appologies, I misused terms foundry/foundries--those should have been type faces or font-families. Tweaked the title a bit--but I think that is going to be resolved invalid.

Rather, what seems to be an issue is how font families with large gaps in uni-code glyph coverage are presented.

Assuming a clean LibreOffice installation of bundled fonts, what should the Special Characters dialog display for uni-code glyphs that are not packaged with a particular font family?

Does the special character dialog show place holders, or simply collapse the character table?

Are glyphs from other fonts ever substituted into the tables and rendered in the dialog? Seems like that would be trouble.
Comment 10 yuntsia 2015-06-17 02:27:19 UTC
I claimed this bug. but how do I confirm whether it is a bug or not since I saw the status is unconfirmed?
Comment 11 semanem 2015-09-07 18:57:17 UTC
Hi. I would recommend this be tagged a bug as it is an issue to be resolved, otherwise nothing happens. I'm writing notes in Writer and sometimes some special symbols I inserted via Unicode don't render (I get the square with the question mark) even they previously did. Presently the antijoin symbol, U+25B7, and the calligraphic G symbols, U+1D4A2, are not rendering.
Comment 12 semanem 2015-09-07 19:42:53 UTC
Also, if the way the app works is to have some fonts support some parts of Unicode, I recommend you install the UCS character repertoire as a base to be used by ALL fonts; you can have the special glyphs for each font override the base fonts, then if some font, e.g. Calibri, does not support the antijoin symbol U+25B7 or calligraphic G, U+1D4A2, then it can revert to the base UCS repoertoire and bring up the character. It would be impractical to instal the UCS(Universal Character Set) repertoire for each distinctive font.
Comment 13 V Stuart Foote 2015-09-07 19:58:24 UTC
Nope, it is invalid--setting it so as work on the Special Character dialog clearly demonstrates glyphs available for a given font.

Each font includes defined subset, and the glyphs as defined for that font--where subsets are defined but no glyph described--a blank will show.  

The LibreOffice Special character dialog correctly shows the described subsets for each font, but correctly omits subsets that are not applicable for a given font.  Result is that some of the cells in the Special Character chart will be empty--that is not a bug, rather there is no glyph described for that value.

Fonts that have glyphs described for values above U+FFFF are correctly displaying and available for use.

For example of fonts with subsets and glyphs defined above U+FFFF, see these LibreOffice deplyed fonts...

Linux Libertine G -- Mathematical Alphanumeric Symbols

Dejavu Sans -- Old Italic, Tai Xuang Jing Symbols, Mathematical Alphanumeric Symbols, Domino Tyles, Playing Cards, Misc Symbols and Pictographs, Emoticons