Description: Unicode pictographs are no longer shown Steps to Reproduce: In any kind of document paste a pictograph character: http://unicode.org/charts/nameslist/c_1F300.html Actual Results: The character isn't shown. Expected Results: The character to be shown. Reproducible: Always User Profile Reset: Yes OpenGL enabled: Yes Additional Info: - It used to work. - It works in non LibreOffice apps. - Source where you copy the char from doesn't affect the end result. - Disabling hardware acceleration or font anti-allising does nothing. - Likely result of the transition to color pictographs. User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36
Can not confirm on Windows builds of current master. Special character dialog, set a font with SMP coverage (e.g. Emoji One color, Symbola) pick place glyphs onto document canvas. Still no color glyph support or the experimental Emoji toolbar (but 105689) on Windows--but any SMP outline glyphs are fine. 🙈🙉🙊 Version: 6.1.0.0.alpha0+ (x64) Build ID: 655b9054bc265de377c3dc411e2ef40cdfd16dce CPU threads: 4; OS: Windows 10.0; UI render: GL; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-03-27_03:21:52 Locale: en-US (en_US); Calc: CL
My operating system is Manjaro Deepin, which is a Linux rolling distribution with the most updated non beta software: https://manjaro.org/community-editions/
it seems to be only linux ... Regression introduced by: author Michael Stahl <mstahl@redhat.com> 2017-09-07 23:01:26 +0200 committer Michael Stahl <mstahl@redhat.com> 2017-09-07 23:22:11 +0200 commit fc670f637d4271246691904fd649358ce2e7be59 (patch) tree 0eee10cd701f0479d4ed8ca7287defefef6af29e parent 554a79d793ee9546f71802643b79001749c3c695 (diff) svtools: HTML import: don't put lone surrogates in OUString The bytes "ed b3 b5" in fdo67610-1.doc (which, as the name indicates, is an HTML file) are converted to the lone UTF-16 surrogate "dcf5", which is inserted into SwTextNode and causes asserts later on. The actual encoding of the HTML document is probably GBK (at least VIM doesn't display any missing characters with that), but because it doesn't contain any indication of its encoding it's apparently imported as UTF-8; the ImplConvertUtf8ToUnicode() thinking a surrogate code point is valid even if the JSON-compatible mode RTL_TEXTENCODING_JAVA_UTF8 is not specified is a bit of a surprise. Bisected with: bibisect-linux64-6.0 Adding Cc: to Michael Stahl
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still present in version 6.2.2.2.
I'm not sure to understand the bug here. On pc Debian x86-64 with master sources updated today + gtk3 rendering, I could copy paste: 🙈🙉🙊 or 🎃 🏆 in a brand new file in Writer. Idem for kf5 and gen rendering. Idem on LO Debian package 6.3.4 with gtk3 rendering. What did I miss?
Screencast: https://youtu.be/eXqBSrJ6Uzk
(In reply to Alberto Salvia Novella from comment #7) > Screencast: > https://youtu.be/eXqBSrJ6Uzk @Alberto, Notice in your screen cast that at the end of your paste that the cursor positioned into the 3 gylphs is showing Liberation Mono--of course there is no coverage of the Unicode SMP glyphs in that font. Position cursor after each "place holder" and issue an <Alt>+X to toggle from glyph to Unicode point. You will probably see correct values of U+1f648 U+1f649 U+1f64a for those glyphs. Meaning the correct unicode is being pasted, but your os/DE has faulty fall back replacement. Simple to work around--select the 3 placeholder glyphs then apply a font that has coverage of these SMP glyphs. The Emoji One Color delivered with LibreOffice has coverage of those symbols from the Supplemental Multilingual Plane and should be available.
Result: https://youtu.be/czPrSYIxhrk
hey I am trying to add Unicode pictographs in the site https://jcpenneyassociatekiosk.live/ . But the problem is i am able o create but it is nto showing. How to solve this ?
You shall install: https://gitlab.com/es20490446e/emoji.conf With an emoji font, like noto-emoji or even better twemoji.