[Libreoffice-bugs] [Bug 115862] Multiple anomalous behaviours in "Bullets and Numbering > Customise > Character" dialogue in Impress.

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Mon Oct 21 10:06:06 UTC 2019


https://bugs.documentfoundation.org/show_bug.cgi?id=115862

--- Comment #7 from Andrew Watson <notinteresting at gmx.com> ---
Followed the "Steps to reproduce" with:

Version: 6.4.0.0.alpha1
Build ID: cc57df8f942f239d29cb575ea5a7cb01405db787
CPU threads: 4; OS: Mac OS X 10.11.6; UI render: default; VCL: osx; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB
Calc: threaded

At step 3, the right click menu once again has a "Bullets and Numbering" item,
so the "Steps to reproduce" can be followed as originally written.

Results are as for 6.3.0.0.alpha0+ above. Namely:

Behaviour 6.1 is STILL FIXED.

Behaviour 6.2.1 is still present. If I change font and the previously-selected
Code Point is available in this font, if the "OK" button was previously
inactive it remains inactive, and I must pointlessly click again on the
selected character to activate the "OK" button to use that Code Point in that
font.

Behaviour 6.2.2 is partly fixed - if the selected font doesn't contain the
desired Code Point, the character box on the right remains blank, and the
message "Missing character" is displayed underneath. However, if the "OK"
button was previously active then it remains so, and can be pressed, which
dismisses the dialogue box. It seems that this always causes the SPACE Code
Point in that font to be selected. Surely it would be more appropriate for the
"OK" button never to be active if the previously-selected Code Point is not
available in this font?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20191021/a94e2293/attachment.html>


More information about the Libreoffice-bugs mailing list