1. Create a Calc document; put "1" into A1. 2. Save the document as "m³ph.ods". Note that "³" is U+00b3 "superscript 3"; possibly one would need different special characters on systems with that character supported by system encoding. 3. Select A1, Ctrl+C to copy to clipboard. 4. Create a new Writer document. 5. Paste Special -> DDE Link. The pasted table is empty, while it is expected to contain "1". The External Links manager shows that source file is "m%3Fph.ods", and its status is "not available". If on step 3, the file name is "m3ph.ods", i.e. does not contain characters not representable in system encoding, then the link is established OK. Examining the ODT content.xml, the reference is like "D:\Documents\m?ph.ods", so the character had been converted to "?" (which corresponds to the percent-encoded data shown by External Links). Replacing it to "D:\Documents\m³ph.ods" manually in the XML makes the ODT open with correct data from the link. Tested with Version: 7.4.2.1 (x64) / LibreOffice Community Build ID: 681d65acd9ede00dd724d6716f21cabfdcc95bd2 CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL Likely Windows-specific (or at least specific to non-Unicode system encoding).
I can repro with 'HelloⱤtest.ods' (Liberation Serif, 'Ɽ' Hex:2C64 Dec:11364) not with "³" is U+00b3 "superscript 3" Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 6834fda784f3066a89838cd6cda4fe945f4c7904 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
Issue also happens with LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
FTR: The problem arises from the use of "Link" clipboard format, which is documented at [1]. The format uses 8-bit encoding to pass application, topic and item elements; and since they are, per DDE spec, case insensitive, and the format doesn't depend on e.g. CF_LOCALE standard clipboard format [2], we can't easily change that format to use e.g. UTF-8, without breaking other possible applications using our DDE server. OTOH, since the format is defined to terminate with two nulls, we possibly could append our custom data after those nulls, which we could tag (to avoid conflicts with other possible extensions). See e.g. the code that reads that format, at SwTransferable::PasteDDE [3]. [1] https://learn.microsoft.com/en-us/windows/win32/dataxchg/using-dynamic-data-exchange#initiating-a-data-link-with-the-paste-link-command [2] https://learn.microsoft.com/en-us/windows/win32/dataxchg/standard-clipboard-formats [3] https://opengrok.libreoffice.org/xref/core/sw/source/uibase/dochdl/swdtflvr.cxx?r=4b95451f#2587
*** Bug 160443 has been marked as a duplicate of this bug. ***
https://gerrit.libreoffice.org/c/core/+/165607
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/db1de445ea67e7f888664531e0bd2d82cde7b46d tdf#151413: add UTF-8 data to the Link clipboard format It will be available in 24.8.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.