Bug 151413 - Unable to create a DDE link to a file with special characters in name on Windows
Summary: Unable to create a DDE link to a file with special characters in name on Windows
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Files-Linked
  Show dependency treegraph
 
Reported: 2022-10-07 17:00 UTC by Mike Kaganski
Modified: 2023-02-21 02:14 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2022-10-07 17:00:23 UTC
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).
Comment 1 m_a_riosv 2022-10-08 12:02:55 UTC
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
Comment 2 m_a_riosv 2022-10-08 12:11:31 UTC
Issue also happens with
LibreOffice 3.3.0 
OOO330m19 (Build:6)
tag libreoffice-3.3.0.4
Comment 3 Mike Kaganski 2022-10-09 08:55:08 UTC
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