Can not reproduce on Windows 10 Home 64-bit en-US, Intel 620 GPU (Driver Version	23.20.16.4982) with

Version: 6.1.0.0.alpha0+ (x64)
Build ID: d246aa574571409046619254292698184c2545a3
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-04-16_02:10:59
Locale: en-US (en_US); Calc: CL

The Special character dialog appearance does not shift. Filling up each the 16 recents slots will refresh the GUI, and once full will shift and redraw the list--but the size of the glyph does not noticeably change.

Could it be font related (a fallback to populate the favorites or recents)? 
What font are you working in?

Otherwise maybe GPU? Does it change with OpenGL rendering disabled, or without HA so just CPU rendering?

Created attachment 141399 [details]
Screencast

I still can't reproduce. But do notice in the screencast that the font from the Recent characters is not Liberation Serif--what Sans font is it? I thought maybe Consolas, but the shape of the G and the 6 is off.

For testing we can recreate the recents from any font by picking out the string "VYJ63ch:&GuWE"

And you'll notice that the Recent characters, and the Favorite characters as well, record both the Unicode glyph but also the source font--so could be that if working with some odd font (with bad metrics) that we could get something like this. I can't force it though, and wonder if it would clear for you with a reset profile to use font defaults.

Also, when you are clicking to change the selected glyph--rather than its Unicode name, the glyph preview on the right is showing "Space" and the Hex is shown 20? So that seems off (and can not reproduce that at all).

Created attachment 141405 [details]
Screencast

> Also, when you are clicking to change the selected glyph--rather than its
> Unicode name, the glyph preview on the right is showing "Space" and the Hex
> is shown 20? So that seems off (and can not reproduce that at all).

I could reproduce this after a profile reset. STR

1. Launch Writer with a clean profile
2. Insert some symbols with the special character dialog 
3. Select the Space button (single click)
5. Switch between Recent Character/ Favorite character -> Hex 20

---
And you'll notice that the Recent characters, and the Favorite characters as
well, record both the Unicode glyph but also the source font--so could be that
if working with some odd font (with bad metrics) that we could get something
like this. I can't force it though, and wonder if it would clear for you with a
reset profile to use font defaults.

-> I tried a profile reset -> No change as far I can tell.. but I'm not noticing the issue anyway (new screencast attached)

Version: 6.1.0.0.alpha0+
Build ID: 9c4eaa7b81a40d97fe49b85272b40bfeaaf44f86
CPU threads: 4; OS: Windows 6.3; UI render: GL; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-04-16_03:31:36
Locale: nl-NL (nl_NL); Calc: CL

OK the second screencast shows pretty clearly it is not from an odd font.

So, what happens if you disable OpenGL? What GPU and driver pair are you working with on Windows 8.1? Does changing to Default with HA, or just CPU rendering affect things?

(In reply to V Stuart Foote from comment #5)
> OK the second screencast shows pretty clearly it is not from an odd font.
> 
> So, what happens if you disable OpenGL? What GPU and driver pair are you
> working with on Windows 8.1? Does changing to Default with HA, or just CPU
> rendering affect things?


---
The cause is quite specific in my case. I tweaked the font size a bit.
Control Panel > Appearance and Personalisation > Display > Make text and other items larger or smaller.

Here you can change the font size of title bars, menus, message boxes, palette titles, icons or tooltips..

However, the same happens with Scale and layout set to 150%
In Windows: Select the Start  menu, then type change display settings in the search box on the taskbar. From the list of results, choose Change display settings and then choose the size under Scale and layout.

OK, I took a Windows 10 box from 100% to 150% and I do see a shifted rendering placement in the dialog, not exactly what you'd screen-cast but noticeable.

Guess question would be is why it calculates a different scale depending on if the glyph is selected from the Favorites or from the Recent bar--and whether it is worth it to fix?

Reproduced in

Version: 6.1.0.0.alpha0+
Build ID: b07e8a7e16ba69e822a309ec280d1987f90021a3
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

but not in

Version: 6.1.0.0.alpha0+
Build ID: b07e8a7e16ba69e822a309ec280d1987f90021a3
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group

Also reproduced in

Version: 6.0.0.0.alpha1+
Build ID: 6eeac3539ea4cac32d126c5e24141f262eb5a4d9
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded

So looking at this again, if I modify the DE to set a font scaling (e.g. on Windows 100% -> 150%) it really just seems the packing of elements in the Special Character dialog shift--the label width+padding for button holding the label for the "Remove from Favorites" is widened which then makes the glyph preview wider when the Favorite Characters list has focus--and both shrink when the label toggles to the "Add to Favorites".

With the DE font scaling at 100%, the label for the "Remove from Favorites" fits in the space allocated and there is no shift visible moving between the Recent/Favorites or the charmap picker.

Is there something hard coded in the packing?

looks to me that the "remove..." text is simpler wider than the initial "add..." text for the button whose label changes so the layout changes to adjust. If the width is set to the max of the two width then I imagine the problem would go away. https://gerrit.libreoffice.org/#/c/57717/

Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

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

tdf#117038 set button width to max possible content width

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.

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=5e5e49eba37c15b17a4d9788da91415abbca4eb1&h=libreoffice-6-1

tdf#117038 set button width to max possible content width

It will be available in 6.1.0.2.

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 that fix it ?

On windows 10 Pro 64-bit en-US with
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

The layout is stable now when DE has font scaling beyond 100%, at 150% no shift in the glyph preview when I toggle between the Recent and the Favorites icon bars and the button label changes between Add to Favorites/Remove from Favorites.

Thanks Caolán!