Create some text box, enter, e.g., "↓↑" and choose as font "OpenSymbol". Copy those character - and paste them somewhere. The font is change to "StarSymbol". (According to the font list, only "OpenSymbol" exists but no "StarSymbol".)
** 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 on a currently supported version of LibreOffice (4.3.5 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) Thank you for your help! -- The LibreOffice QA Team
Reproduced. Win 7 Pro 64-bit Version: 4.5.0.0.alpha0+ Build ID: 07e84cae983c08afdba03018413a19d01abb3006 TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-01-19_06:15:38
** 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 on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) 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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Bug reproduced. Bug remains.
Product: LibreOffice Component: Impress Versión 5.2.2.2+ Hard. AMD64 SO: Linux (Debian Jessie) Bug reproduced. Bug remains.
** 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
Dear Tobias Burnus, 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 https://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
Was reviewing this (while looking at bug 101174). We are no longer getting a StarSymbol font name, so can close. But I think we have a logic issue on the font PUA mapping done with [1]. Copy - Paste is getting garbled. But Copy - Paste Special 'Unformatted text' receives the correct Unicode in the paragraph font (with fallback to OpenSymbol for glyphs). Working with the string, all in OpenType: »†‡€ --> U+00bbU+2020U+2021U+20ac I get that string with paste special 'Unformatted Text' (so it falls back to OpenSymbol) But I get nonsense --> U+f0bbU+f086U+f087U+f080 with Paste (i.e. as OpenSymbol). So we seem to have some PUA map occurring for a paste as OpenSymbol, and the codepoints look to match fontcvt.cxx assignments. =-ref-= [1] https://opengrok.libreoffice.org/xref/core/unotools/source/misc/fontcvt.cxx?r=a7f74d5d
Created attachment 163496 [details] sample ODT showing PUA Unicode being applied to OpenSymbol glyphs So this really is continuing. Just the StarSymbol font name is not being applied: STR for attached document 1. new Writer document 2. insert a draw Text box on document 3. use Special character dialog and select OpenSymbol font 4. enter a string of OpenSymbol glyphs via Special Character dialog 5. change anchor to page and drag aside 6. Ctrl+C select the string in the Draw text box 7. paste into a paragraph with Ctrl+V -- what is pasted? 8. paste special into a paragraph with Ctrl+Shift+V and select unformatted -- what is pasted? 9. new paragraph, change its font to OpenSymbol 10. Ctrl+C copy string from Draw text box 11. Ctrl+V paste into the paragraph with OpenSymbol font -- what is pasted? 13. Ctrl+Shift+V paste special as "unformatted text" -- what is pasted? At some point the labeling of the pasted OpenSymbol text string as StarSymbol was removed--but the handling of OpenSymbol and mapping of the Unicode to PUA was not corrected. Pasting a string of OpenSymbol should retain the assigned Unicode for the font. Behavior now seems a hold over from StarOffice era.
Dear Tobias Burnus, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
(In reply to QA Administrators from comment #11) issue of OpenSymbol fallback / translation to old StarSymbol PUA tables [1] continues... =-ref-= [1] https://opengrok.libreoffice.org/xref/core/unotools/source/misc/fontcvt.cxx?r=04a58d7e
I don't think comments #9 and '10 are a starsymbol vs opensymbol thing, or related to the fontcvt.cxx conversion tables. I think its an issue with the editengine rtf export which is used for this copy and paste route. (and if you copy into another drawing edit box then ODF is used, not RTF) In ImpEditEngine::WriteRTF we write the fonts and the font charset, opensymbol is flagged as a "symbol" font and we write fcharset2 to set the charset as SYMBOL encoding, but when we write the text we always attempt to write it using eDestEnc which is RTL_TEXTENCODING_MS_1252 (0), the characters in this case can be expressed in MS1252 so they are written as 0x80, 0x87, 0x86, 0xbb which is correct for MS_1252 encoding (https://en.wikipedia.org/wiki/Windows-1252) but nonsense for symbol encoding. Its probably an error that we consider OpenSymbol a "Symbol" font as its not the classic "Symbol" font, but its probably also an error for the rtf export to set a fcharset on the font but then ignore that when writing the text. The cheapest thing to do I think it to specifically not write "fcharset2" for opensymbol in the editeng export. Longer term to probably disentangle what a "SymbolFont" is.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a4a865a85cfc922e75ed2ad5188e45a76bca92aa tdf#47679 explicitly don't write fcharset2 for text in OpenSymbol It will be available in 7.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Testing attachment 163496 [details] with Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: bcf333309f9a9bde21aac1302cbead2b23822458 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded For string U+20AC U+2021 U+2020 U+00BB or a fully Open Office PUA string, e.g. U+e11aU+e691U+e690U+e593U+e594 Confirm handling of the copy/paste and copy/paste special (unformatted or RTF) is now consistent. But I do see that the handling of PUA glyph fallback around OpenSymbol is doing some odd things with the sample document prepared with 7.0.0 Seems font "selection" has changed considerably (between 7.0.0 and 7.5.0) on Windows for fallback mapping U+f080 U+f087 U+f086 U+f0bb PUA -- but I think that is to be expected as those specific codepoints are not (never were?) present in OpenSymbol PUA space and got StarSymbol/StarBat mappings, and the test document as structured is no longer applicable for testing OpenSymbol PUA. Better OpenSymbol specific PUA string (no StarBat, StarSymbol lookups) might be: U+e11aU+e691U+e690U+e593U+e594
> or a fully Open Office PUA string s/Open Office/OpenSymbol
so, I think this is fixed, but I'm unsure from comment #15 if there is something outstanding and if so what are the steps to reproduce the problem?
Yes it is fixed. The copy/paste works as expected. Font conversion is no longer an issue and the OpenSymbol fallback is behaving, i.e. copying a string of OpenSymbol PUA (U+e11aU+e691U+e690U+e593U+e594), <Alt>+X converting, copying glyphs, pasting to different module, <Alt>+X converting back. The Unicode PUA remains intact (no table lookup), and the fallback for the OpenSymbol PUA results in OpenSymbol -- even when pasted as unformatted text. I think this is what we want. I think I was confused/wrong about the StarBat, StarSymbol table lookups in fontcvt.cxx--which now with removing the StarSymbol handling are even more orphaned. The mislabeling and then mishandling of symbol font, assigning MS_1252 encoding, suggested in comment 13 is much more likely.
I should note that I was testing on Windows 10 with Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: bcf333309f9a9bde21aac1302cbead2b23822458 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Functional on Windows, but font fallback for the PUA strings to preferentially use OpenSymbol could differ with other os/DE. Might need to check...
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/9366ae27af45473cb2f557389d396df1819fae53 tdf#47679 explicitly don't write fcharset2 for text in OpenSymbol It will be available in 7.4.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.