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
Created attachment 142998 [details] Special characters – Wrong graphical illustrations
(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
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.)
(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
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.
(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?
I sounds to me like you need to be fired from Canonical today or any time tomorrow; just try to do it with what is called honour. You made clear you don't have any. You are on your own with your comments.
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.
(In reply to ricky.tigg from comment #7) > I sounds to me like you need to be fired from Canonical today or any time > tomorrow; just try to do it with what is called honour. You made clear you > don't have any. You are on your own with your comments. Nyt menee kyllä överiksi - mitä ihmettä sä selität? Miten Canonical liittyy tässä mihinkään? Olet itse siitä joka paikassa puhunut, niin on tullut sellainen käsitys, että sulla on jotain sen kanssa tekemistä. Canonical ei osallistu tällä hetkellä ollenkaan LibreOfficen kehitykseen - tuliko selväksi? Minä en ole minkään yrityksen palkkalistoilla LibreOfficeen liittyen. Yritän tässä parhaani mukaan sua ilmaiseksi jeesata, niin tyyppi vaan linkoaa paskaa niskaan. Jos sulta vielä tulee tollaista aggressiivista läppää, niin saat bännit.
THat was good to laugh; I did not need that since I am anyway mostly a funny person, but I felt sad for you, so I can't thank for it. There is always a guy – its your case then– frustrated, no real friends, if not at all– and only spoke on forums or here as a forum. Strange how thing are around you. Sounds like its not your first time; messing, with me or with people –most probably–. No need to know where do you come from –the very origin–, or what you are. Just keep on being that person with no honour; it suits you good. So you heard about that you too was entitled the power to ban anyone that –happily– is not at all like you. It sounds good isn't it, are you then tempted? Sure for the kind of frustrated you are in your life. So here is my advice and even for free. Do play that game; it won't bring any honour back to those of your kind, and I won't feel affected but certainly amused. As soon as possible go for a walk meditating why your life has no purpose when you end writing those things to me in a language no one speak. I could see how confused you currently were in English –trying what is your best–. while others –real developers– have another kind of 'trying their best' since they remain ethically within the the developer work sphere. So that is one more professional competence you to lack. All that is probably not knew for others with who you vainly try to be one of them. That was just expectable to be said one day by a reporter, and that's now.
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)
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.
does the above commit solve the substantive problem ?
(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.
(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
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.
*** Bug 118818 has been marked as a duplicate of this bug. ***
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.