https://bugs.documentfoundation.org/show_bug.cgi?id=118304
V Stuart Foote <vstuart.fo...@utsa.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |caol...@redhat.com,
| |qui...@gmail.com
Summary|Graphical illustrations |Preview glyph and charmap
|regarding characters are |of selected Unicodepoint
|not displayed according to |does not behave when
|the font that the |changing to a font without
|application itself chose to |coverage of the codepoint
|focused on. |
OS|Linux (All) |Windows (All)
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #11 from V Stuart Foote <vstuart.fo...@utsa.edu> ---
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)
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
