Bug 47679 - Copy + Paste changes "OpenSymbol" font to "StarSymbol"
Summary: Copy + Paste changes "OpenSymbol" font to "StarSymbol"
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
3.5.1 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.5.0 target:7.4.4
Keywords:
Depends on:
Blocks: Font-Rendering Clipboard
  Show dependency treegraph
 
Reported: 2012-03-21 13:11 UTC by Tobias Burnus
Modified: 2022-11-22 09:43 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
sample ODT showing PUA Unicode being applied to OpenSymbol glyphs (925.87 KB, application/vnd.oasis.opendocument.text)
2020-07-24 21:17 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2012-03-21 13:11:36 UTC

    
Comment 1 Tobias Burnus 2012-03-21 13:14:30 UTC
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".)
Comment 2 QA Administrators 2015-01-05 17:51:15 UTC Comment hidden (noise)
Comment 3 Buovjaga 2015-01-21 16:01:04 UTC
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
Comment 4 QA Administrators 2016-09-20 10:10:25 UTC Comment hidden (noise)
Comment 5 José Trujillo 2016-11-11 19:35:56 UTC Comment hidden (obsolete)
Comment 6 José Trujillo 2016-11-11 19:38:07 UTC
Product: LibreOffice
Component: Impress
Versión 5.2.2.2+
Hard. AMD64
SO: Linux (Debian Jessie)

Bug reproduced.
Bug remains.
Comment 7 QA Administrators 2018-07-03 02:39:09 UTC Comment hidden (noise)
Comment 8 QA Administrators 2020-07-03 03:40:22 UTC Comment hidden (noise)
Comment 9 V Stuart Foote 2020-07-24 16:11:46 UTC
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
Comment 10 V Stuart Foote 2020-07-24 21:17:33 UTC
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.
Comment 11 QA Administrators 2022-11-12 03:35:40 UTC Comment hidden (noise)
Comment 12 V Stuart Foote 2022-11-12 06:21:30 UTC
(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
Comment 13 Caolán McNamara 2022-11-18 11:20:39 UTC
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.
Comment 14 Commit Notification 2022-11-18 13:55:43 UTC
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.
Comment 15 V Stuart Foote 2022-11-19 21:09:43 UTC
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


Comment 16 V Stuart Foote 2022-11-19 21:11:02 UTC
 
> or a fully Open Office PUA string

s/Open Office/OpenSymbol
Comment 17 Caolán McNamara 2022-11-21 10:03:16 UTC
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?
Comment 18 V Stuart Foote 2022-11-21 16:29:47 UTC
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.
Comment 19 V Stuart Foote 2022-11-21 17:09:11 UTC
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...
Comment 20 Commit Notification 2022-11-22 09:43:16 UTC
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.