Description: I tested new 'special characters UI' on LBO6.0.0.0.beta2 I wrote in 'Hexadecimal: U+' window on Special Characters UI. The Special character didn't show in upper right window. So,I testd LBO5.4.2.1. It was OK. I think BUG. Steps to Reproduce: 1.Click 'Insert Special Characters' Icon. Click 'More Characters' Icon on Favorites UI. 2.Write in 'Hexadecimal: U+' window on Special Characters UI. ex: U+'845B'. 3.The '葛' character don't show in upper right window. Actual Results: The '葛' character don't show in upper right window. Expected Results: I think it is necessary to modify the code. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:57.0) Gecko/20100101 Firefox/57.0
I tested it. Version: 6.0.0.0.beta2 Build ID: 13edaaa12f25de343fce136064e27da66c1c4fa4 CPU threads: 4; OS: Windows 10.0; UI render: default; Locale: ja-JP (ja_JP); Calc: group threaded
Created attachment 138515 [details] specilalcaracter UI on 6.0.0.0.beta2 Specilal caracter UI on 6.0.0.0.beta2 The Special character didn't show in upper right window.
Created attachment 138516 [details] Special caracter on LBO5.4.2.1 Special caracter UI on LBO5.4.2.1. I tested LBO5.4.2.1. It was OK.
I can reproduce this one. I guess m_pShowChar's text is changed when m_pShowSet is focused https://opengrok.libreoffice.org/xref/core/cui/source/dialogs/cuicharmap.cxx?a=true&r=2432c550&h=994#994 but strangely not when either m_pHexCodeText or m_pDecimalCodeText is modified. also note that setCharName is called even when m_pShowSet is NOT focused for comparison: when we click a character in m_pShowSet, SvxShowCharSet::SelectIndex is called, and as second parameter is explicitly specified true rather than default false, m_pShowSet grabs focus, successfully changing m_pShowChar's text.
oh, I forgot to include: Version: 6.1.0.0.alpha0+ (x64) Build ID: aad9c6da5154a89c6ef02214d1122d4b444eea23 CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2017-12-16_00:07:36 Locale: en-US (ja_JP); Calc: CL
submission done https://gerrit.libreoffice.org/#/c/51616/ waiting for Jenkins and Code-Review on Gerrit.
himajin100000 committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fa17a6021f79374ba0e4e010587fa01774805da5 tdf#114549:entering hex/dec code should change char sample 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.
When I wrote this patch before, it worked with my own build, but at least with Version: 6.1.0.0.alpha1+ (x64) Build ID: 4c5b4752786ae2c174cd8fa8aa42b27a0994f34a CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-05-08_23:43:34 Locale: en-US (ja_JP); Calc: CL my patch seems not working well. I'll look into the reason for this.(I wish I wasn't facing build errors)
More comments to Clarify: m_xSubsetLB does not have some entries like Hiragana
1. Follow Tools->Options Advanced Open Expert Configuration org.openoffice.VCL DefaultFonts en org.openoffice.VCL:LocalizedDefaultFont['en'] UI_SANS 2. Add IPAPGothic; in front of Segoe UI; 3. Restart LibreOffice With these steps, I confirmed that inputting 3042 into "Hexadecimal: U+" will change the upper-right image to the "あ" character. please note that changing org.openoffice.VCL:LocalizedDefaultFont['ja'] UI_SANS does not work.
Issue as in OP on Windows 10 Pro 64-bit en-US with Version: 6.0.4.2 (x64) Build ID: 9b0d9b32d5dcda91d2f1a96dc04c645c450872bf CPU threads: 8; OS: Windows 10.0; UI render: GL; Locale: en-US (en_US); Calc: group Testing with font selection of Arial Unicode MS (so coverage of CJK in BMP) But with current master Version: 6.2.0.0.alpha0+ (x64) Build ID: abb19edc79bd7d96827214d3b49f80e270e1c0b7 CPU threads: 8; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-06-06_17:02:23 Locale: en-US (en_US); Calc: group threaded With https://cgit.freedesktop.org/libreoffice/core/commit/?id=fa17a6021f79374ba0e4e010587fa01774805da5 the Hexadecimal field search works now for non-CJK Unicode subsets and a glyph is shown. What is weird is that you can enter FEFC (or decimal 65276) and show "ARABIC LIGATURE LAM WITH ALEF FINAL FORM" from Arabic Presentation Forms-B, but moving into the Halfwidth and Fullwidth Forms and entering FF01 in the Hex field--the dialog returns missing glyph rather than FULLWIDTH EXCLAMATION MARK. A glyph which is shown in a cell on the font grid and that can be selected/inserted. Other CJK glyphs in the font, and present on the grid of Arial Unicode MS, also show "Missing Glyph" when entered by Hex or Decimal value. Yet they can be selected/inserted from the grid with scroll and mouse click. Also, when a CJK glyph is selected from the grid, there is no corresponding Unicode subset, e.g. selecting F9D1 does not show "CJK compatability Idiographs" subset. While I tried toggling on CJK language support--but that does not seem to affect things. Neither OpenGL nor Default rendering changes result. Is mishandling Unicode script ID another facet of the CommonSalLayout font handling regression--bug 117936 so we get the new "Missing Glyph" label.
removing the block of bug 117936, testing today's master/6.2 build does not resolve issues of missing glyph and lack of Unicode support for the CJK unified subset, or of support for charts from the Unicode SMP supplemental plane.
(In reply to V Stuart Foote from comment #11) > What is weird is that you can enter FEFC (or decimal 65276) and show "ARABIC > LIGATURE LAM WITH ALEF FINAL FORM" from Arabic Presentation Forms-B, but > moving into the Halfwidth and Fullwidth Forms and entering FF01 in the Hex > field--the dialog returns missing glyph rather than FULLWIDTH EXCLAMATION > MARK. A glyph which is shown in a cell on the font grid and that can be > selected/inserted. > > Other CJK glyphs in the font, and present on the grid of Arial Unicode MS, > also show "Missing Glyph" when entered by Hex or Decimal value. Yet they can > be selected/inserted from the grid with scroll and mouse click. > Actually, it does support and searchable when the settting in Comment 9 is set appropriately. Instead of IPAexGothic, we can bring "Arial Unicode MS"; the fonts that has hiragana subset. >(from tdf#118681) >- keyboard entry is not sequential, text cursor of input field jumps to start with each Hex pair. Makes it difficult to reliably enter the codepoint--and finding a glyph in the SMP (e.g. for Emoji) is a real chore So far I have been unable to reproduce the unreliable input of codepoint, but today I encountered a similar situation when I was testing on my PC. I still haven't checked (and would not be able to check anytime soon because of the compile error with VS 2017 15.8 Preview 3.0 and 4.0) whether this is the cause, but U+3042 for example, the font for the middle dropdown needs to have U+0030 and U+0304 for the reliable input and I have overlooked that when I wrote the patch?
typo: Comment 9 => Comment 10 Instead of IPAexGothic => Instead of IPAPGothic
So, if you add Noto Sans Symbols as the very first font to org.openoffice.VCL:LocalizedDefaultFont['en'] UI_SANS ,restart LibreOffice, Open Special Characters Dialog, and inputting 1D15F to Hexadecimal entry text box, musical note will be shown.
>the font for the middle dropdown needs to have U+0030 and U+0304 Hmmm.... if so, why is "Missing Glyph" string isn't used in that case?
This now works for me [1]... Could we retest with current master? [2] Beleive Tomoyuki's earlier patch here, and Caolán's work on bug 118681 has got the font handling sorted. Remember though that the font being searched, as set from the droplist of current paragraph in the document, must actually include the glyph for anything other than Missing glyph to show. The font chart is not a "composite" of multiple fonts--just what that font contains. =-Ref-= [1] Version: 6.2.0.0.alpha0+ (x64) Build ID: daafe79c55cd53decbeac2367f298d79371dcf3d CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-07-18_02:59:18 Locale: en-US (en_US); Calc: CL [2] https://dev-builds.libreoffice.org/daily/master/
seems working well on my PC too *musical note searchable without need for the change in DefaultFont settings in advance, just needed to change the Font combobox. *Reliable hex code input.
Version: 6.2.0.0.alpha0+ (x64) Build ID: daafe79c55cd53decbeac2367f298d79371dcf3d CPU threads: 4; OS: Windows 10.0; UI render: default; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-07-18_02:59:18 Locale: ja-JP (ja_JP); Calc: CL
as for bug 118681... http://cgit.freedesktop.org/libreoffice/core/commit/?id=a09d357daf65e285323ff77653a6de3058fc44da&h=libreoffice-6-1 http://cgit.freedesktop.org/libreoffice/core/commit/?id=805ea77cf21ff96f8ffd091f94726840771ee658&h=libreoffice-6-1