Download it now!
Bug 118304 - Preview glyph and charmap of selected Unicodepoint does not behave when changing to a font without coverage of the codepoint
Summary: Preview glyph and charmap of selected Unicodepoint does not behave when chang...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.0.4.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.2.0 target:6.1.0
Keywords:
: 118818 (view as bug list)
Depends on:
Blocks: Special-Character
  Show dependency treegraph
 
Reported: 2018-06-21 13:28 UTC by ricky.tigg
Modified: 2018-09-08 04:03 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
Special characters – Wrong graphical illustrations (60.21 KB, image/png)
2018-06-21 13:30 UTC, ricky.tigg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ricky.tigg 2018-06-21 13:28:51 UTC
Description:
Graphical illustrations regarding characters are not displayed according to the font that the application itself chose to focused on. See attachment

Steps to Reproduce:
1. Select a character, e.g. LEFTWARDS ARROW OVER RIGHTWARDS ARROW (Hexa: 21C6; Deci: 8646). Selected item is individually displayed on blue background.
2. Lets search for available characters whose specification are LEFTWARDS ARROW OVER RIGHTWARDS ARROW, Hexa: 21C6 and Deci: 8646.

Click Font list –doing so, selected item is no longer individually displayed on blue background.– and then scroll through the font list.


Actual Results:

On the right-sided-character-information section, the graphical illustrations regarding characters are no more displayed according to the font that the application itself chose to focused on. See attachment

Expected Results:
Graphical illustrations regarding characters to be displayed according to the font that the application itself chose to focused on.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 6.0.4.2 – Build ID: 6.0.4.2-4.fc28
CPU threads: 2; OS: Linux 4.16; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 1 ricky.tigg 2018-06-21 13:30:55 UTC
Created attachment 142998 [details]
Special characters – Wrong graphical illustrations
Comment 2 Buovjaga 2018-06-28 10:44:40 UTC
(In reply to ricky.tigg from comment #0)
> 1. Select a character, e.g. LEFTWARDS ARROW OVER RIGHTWARDS ARROW (Hexa:
> 21C6; Deci: 8646). Selected item is individually displayed on blue
> background.

What font do you use? I get missing glyph
Comment 3 ricky.tigg 2018-06-28 12:20:36 UTC
Font initially selected is the one illustrated in the left-sided picture as attachment 'Special characters – issue related to character's information.' from Bug 118300 (font C059, character Hexa. and deci. values are respectively 21C6 and 8846.)
Comment 4 Buovjaga 2018-06-28 12:28:00 UTC
(In reply to ricky.tigg from comment #3)
> Font initially selected is the one illustrated in the left-sided picture as
> attachment 'Special characters – issue related to character's information.'
> from Bug 118300 (font C059, character Hexa. and deci. values are
> respectively 21C6 and 8846.)

Yeah, sorry about that... I tried with Caladea (on Linux) and still get missing glyph
Comment 5 ricky.tigg 2018-06-28 19:32:33 UTC
Though state of missing glyph seemed to me the object of the present issue. If not, does that issue has then any relevance for Canonical or does it has to be transferred to Fedora which is the packager of the present Office suite I used.
Comment 6 Buovjaga 2018-06-28 19:39:58 UTC
(In reply to ricky.tigg from comment #5)
> Though state of missing glyph seemed to me the object of the present issue.
> If not, does that issue has then any relevance for Canonical or does it has
> to be transferred to Fedora which is the packager of the present Office
> suite I used.

Are you employed by Canonical or why do you ask?
Comment 7 ricky.tigg 2018-06-28 20:46:55 UTC Comment hidden (abusive)
Comment 8 V Stuart Foote 2018-06-29 01:20:36 UTC
I can not reproduce this on Windows 10 Home 64-bit en-US with either default rendering or OpenGL with

Version: 6.2.0.0.alpha0+ (x64)
Build ID: 7e1cabd96526cb7befc5ea5073358093efbe12d0
CPU threads: 4; OS: Windows 10.0; UI render: default; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-06-28_00:54:11
Locale: en-US (en_US); Calc: CL

However here are more refined STR, require two fonts that contain the glyph for the target Unicode codepoint 21c6--so DejaVu Sans and Cambria

1. set font for Default paragraph to DejaVu Sans
2. set the Unicode subset to "Arrows", i.e. open the droplist and enter A-A-A-A
3. select the target"Leftwards Arrow over Rightwards Arrow"
4. the selected glyph in the grid is highlight Blue
5. double click or use Insert button to insert to document canvas
6. use font font listbox and select Cambria
7. the glyph preview will change to render in the new font--with the U+21c6 glyph present in the Cambria font--a preview is shown

If this is done with a font without coverage of the codepoints from the Arrows block--the grid will be repositioned to a different block and a different glyph from the grid will show "gray" positioned.
Comment 9 Buovjaga 2018-06-29 08:29:41 UTC Comment hidden (no-value)
Comment 10 ricky.tigg 2018-06-29 11:21:12 UTC Comment hidden (abusive)
Comment 11 V Stuart Foote 2018-06-29 15:45:10 UTC
The charmap Special Character dialog has some quirks when the font selected from the droplist does not include the specific codepoint or even the Unicode subset of codepoints.

When the selected font has coverage of the glyph, the glyph preview, focus on the charmap, and the subset droplist will hold on font change--this is correct.

But if the font selected (or changed font selection from droplist) does not contain the glyph--several behaviors seem wrong.

What should the correct behavior(s) be?  

Should the OS provided font substitution offer a replacment glyph? 
- IMHO probably not (we'd loose precision of font use in the ODF)

Should the GUI warn the codepoint is not covered?
-  seems we need attention
-  bcz at present without "warning":
    the position on the charmap shifts erratically,
    the subset droplist shifts,
    the preview glyph picks up a fallback font (wrongly suggesting coverage)
Comment 12 Commit Notification 2018-07-19 14:53:56 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e8bf2cb72dbe55f4e9ac7ace48e644a934cfc503

tdf#118304 reselect current glyph on changing font

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Caolán McNamara 2018-07-19 14:55:12 UTC
does the above commit solve the substantive problem ?
Comment 14 V Stuart Foote 2018-07-20 03:57:37 UTC
(In reply to Caolán McNamara from comment #13)
> does the above commit solve the substantive problem ?

Yes, as from description of commit https://gerrit.libreoffice.org/57724

tdf#118304 reselect current glyph on changing font
preview glyph will rerender the glyph if its there, or the glyph description
changes to "missing glyph" if its not there anymore. Don't auto select
first entry of the subset when font changes, leave it as unselected and
let the glyph determine what's ends up there

So, keeping the current codepoint value when changing fonts, and displaying "Missing Glyph" error is better UX when the font does not contain the search target.
Comment 15 V Stuart Foote 2018-07-20 03:59:07 UTC
(In reply to V Stuart Foote from comment #14)
> Yes, as from description of commit https://gerrit.libreoffice.org/57724
> 
> ...

That was testing on Windows 10 Pro 64-bit en-US with current master/6.2.0
Version: 6.2.0.0.alpha0+ (x64)
Build ID: b7e139fa21607f488465fd87333db757ad0c91a2
CPU threads: 8; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-07-20_01:39:32
Locale: en-US (en_US); Calc: group threaded
Comment 16 Commit Notification 2018-07-20 09:54:41 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a32d9ec1fa48296ffba713bc4593cad45a1c83ad&h=libreoffice-6-1

tdf#118304 reselect current glyph on changing font

It will be available in 6.1.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 17 Xisco Faulí 2018-07-30 21:49:51 UTC
*** Bug 118818 has been marked as a duplicate of this bug. ***
Comment 18 Commit Notification 2018-08-02 19:18:32 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-6-1-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9844eef47a030435fa3d4177cb93b09d05a53fd2&h=libreoffice-6-1-0

tdf#118304 reselect current glyph on changing font

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.