Created attachment 116171 [details] Preview of Special Character is very small. Please make it bigger, bolder and crispier Preview of Special Character is very small. Please make it bigger, bolder and crispier.
Works ok in 4.4. Regression. Win 7 Pro 64-bit, Version: 4.4.3.2 Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16 Locale: fi_FI Version: 5.1.0.0.alpha1+ Build ID: bf9c96238e33f63922af35c0c77ceb83ff447d3e TinderBox: Win-x86@39, Branch:master, Time: 2015-05-27_07:04:47 Locale: fi-FI (fi_FI) Ubuntu 15.04 64-bit Version: 4.4.2.2 Build ID: 40m0(Build:2) Locale: en_US Version: 5.1.0.0.alpha1+ Build ID: be01d68420086fc36ecf26b5f597ba7c6b29b369 TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2015-05-28_03:30:12 Locale: en-US (en_US.UTF-8)
*** Bug 91991 has been marked as a duplicate of this bug. ***
The dialog is ignoring the document font and rendering the grid with the UI font and size.
(In reply to Adolfo Jayme from comment #3) > The dialog is ignoring the document font and rendering the grid with the UI > font and size. confirming on Windows 8.1 with Version: 5.0.0.0.beta3 (x64) Build ID: 96345c15d8ab19c49014f055fe41ba8e1f421e5c Locale: en-US (en_US) Yes but just the repaint of the canvas is corrupt. The Special Characters dialog is not refreshing the display window to display selected fontset. It seems stuck on Liberation Serif and is painting those mappings. But, the working fontset seems to follow drop down, and is making character picks from the selected font if it has corresponding glyphs defined. So, think function is correct, but the display rendering of the dialog is broken.
*** Bug 92078 has been marked as a duplicate of this bug. ***
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=56d62036862462ca7147686268558a754613858f tdf#91748 fix preview of special characters It will be available in 5.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.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "libreoffice-5-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=efc5602dd3a2c2c138e0290e58ed1527523e4dcf&h=libreoffice-5-0 tdf#91748 fix preview of special characters It will be available in 5.0.0.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.
Created attachment 116822 [details] LO50RC1 still has the problem on OSX Sorry, but I can still see this in LO50RC1 on OSX.
Did you try to select another character - one that is not "space"? :)
Created attachment 116825 [details] Another proof Tomaž, seveda, of course I did.
(In reply to miles from comment #8) > Created attachment 116822 [details] > LO50RC1 still has the problem on OSX > > Sorry, but I can still see this in LO50RC1 on OSX. The problem is also still present on Linux x86_64
*** Bug 92356 has been marked as a duplicate of this bug. ***
Yeah, only the preview in the right side got fixed, but not the grid.
*** Bug 92435 has been marked as a duplicate of this bug. ***
http://cgit.freedesktop.org/libreoffice/core/commit/?id=ac7cc2b709469f1b88fe67dd8d069512ade6eb1c&h=libreoffice-5-0 fixed the grid.
*** Bug 92904 has been marked as a duplicate of this bug. ***
The grid of gylyps for selected fonts is still not redrawn correctly on drop down selection of font, as in dupe bug 92904
Doesn't seem like any bibisection is required here, so removing bibisectRequest
Still affected (experiencing the symptoms described in the several duplications) on Ubuntu 14.04 LTS 64-bit with LibO Version: 5.0.0.5, Build ID: 00m0(Build:5), Locale: en-GB (en_GB.UTF-8). Am looking forward to a fix arriving in my neck of the woods!
On Windows 10 Pro 64-bit en-US with Version: 5.0.3.1 (x64) Build ID: fd8cfc22f7f58033351fcb8a83b92acbadb0749e-GL Locale: en-US (en_US) as well as Version: 5.1.0.0.alpha1+ Build ID: 07bc49b43187ecc691d98eec1b9b129cf92efd70 TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-10-15_22:30:35 Locale: en-US (en_US) Residual issues of dupe bug 92904 do seem to be resolved. STR 1. Open Writer 2. Open Special Character dialog 3. select "Liberation Serif" in fontlist dropdown 4. navigate to the "Miscellaneous Symbols" on the subset drop down 5. select a sharp ♯ (U+266F) grid of glyphs defined in Liberation Serif is rendered, with preview of the ♯ 6. select "DejaVu Sans" in fonlist dropdown different grid of glyphs as defined in DejaVu Sans is rendered, and ♯ changes 7. select "Caldea" in fontlist dropdown (or another font without a glyph for ♯) different grid of glyphs as defined in Caldea is rendered--there is no U+266F glyph defined and the ♯ preview receives a substitution (I can't tell which font or the mechanism of that substitution). But, this all seems to be working correctly now for 5.0.3 and 5.1.0alpha1+ (master). Please test, but closing WFM. =-= p.s. - It might be better if the preview in a case where the glyph is not defined for the font showed a generic "not defined this font" error. But that would be a different issue.
(Using Ubuntu 14.04.3 with LO 5.0.2.2) I have to second the P.S. by V. Stuart Foote. Specifically, if a character/glyph is displayed on the right side of the Insert Special Characters dialog, and a different font is then chosen that doesn't contain that character/Unicode block, the "Subset" becomes blank and the previous sample character (in the previous font) remains displayed along with the grid of lower ASCII characters from the new font. Of course, once a valid Subset for the new font is chosen, things correct themselves, but this could be confusing to many users and isn't very elegant. Clearing the sample character display upon any new selection in the Subset OR font before proceeding would seem to be called for. But the regression itself seems to have been corrected.