Issue 9709 - OLE/DDE link from Calc to Writer trashes non-ASCII characters (special characters, umlauts)
Summary: OLE/DDE link from Calc to Writer trashes non-ASCII characters (special charac...
Alias: None
Product: Calc
Classification: Application
Component: code (show other issues)
Version: OOo 1.1
Hardware: PC Linux, all
: P3 Trivial with 53 votes (vote)
Target Milestone: ---
Assignee: oc
QA Contact: issues@sw
Keywords: oooqa
: 15540 27009 51603 51740 65867 66342 72695 73246 77749 81049 (view as issue list)
Depends on:
Reported: 2002-11-30 23:12 UTC by slothman
Modified: 2013-08-07 15:14 UTC (History)
12 users (show)

See Also:
Issue Type: PATCH
Latest Confirmation in: ---
Developer Difficulty: ---

Spreadsheet source for OLE link (5.31 KB, application/octet-stream)
2002-11-30 23:14 UTC, slothman
no flags Details
Writer document demonstrating OLE link (9.24 KB, application/octet-stream)
2002-11-30 23:15 UTC, slothman
no flags Details
Patch to file sc/source/core/tool/ddelink.cxx (470 bytes, text/plain)
2007-06-11 23:22 UTC, elmede
no flags Details
Corrected Patch to file sc/source/core/tool/ddelink.cxx (416 bytes, text/plain)
2007-06-19 03:23 UTC, elmede
no flags Details
Proposed patch (1.56 KB, patch)
2008-02-21 22:14 UTC, rail_ooo
no flags Details | Diff
Writer OOo-dev 3.1 .0 (OOO310m7 Build:9393) for Windows XP (97.36 KB, text/plain)
2009-04-01 18:53 UTC, vladimir_hitekschool
no flags Details
Calc OOo-dev 3.1 .0 (OOO310m7 Build:9393) for Windows XP (63.38 KB, text/plain)
2009-04-01 18:55 UTC, vladimir_hitekschool
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description slothman 2002-11-30 23:12:40 UTC
I'm running OpenOffice 1.0.1-8 on Red Hat Linux 8.0 with kernel 2.4.18-18.8.0 on
an i686.

I've been using the OpenOffice Calc to do some complex calculations and using
the OLE facility to insert windows into the results into an OpenOffice Writer
document to control layout.  (This is easily done:  create your spreadsheet,
then create a writer document, insert a new OLE spreadsheet, copy a region of
the actual spreadsheet, select the new spreadsheet you just inserted in the
Writer document, Paste Special..., choose Link.)

If the spreadsheet contains non-ASCII characters, they are garbled when they are
displayed in the Writer document.  (Using kcharselect, select the "1/2" icon and
paste it into a cell in your spreadsheet; you'll get multiple bytes of other
characters in your writer document.)

This appears to be relatively new behavior.  (Older behavior I've had to cope
with included reading the formatted value of a cell instead of the raw data-- if
I had a user-defined numeric format of [>0]#"";[<0]""#;"&#8210;" in the spreadsheet,
positive numbers would be read as negative in the DDE version.)

I will attach a pair of files that demonstrate this behavior; since DDE links
are absolute in the filesystem, you'll want to read them in /tmp, where they
have the names test.sxw and test.sxc.
Comment 1 slothman 2002-11-30 23:14:55 UTC
Created attachment 3825 [details]
Spreadsheet source for OLE link
Comment 2 slothman 2002-11-30 23:15:32 UTC
Created attachment 3826 [details]
Writer document demonstrating OLE link
Comment 3 h.ilter 2002-12-03 15:51:55 UTC
Reassigned to MRU
Comment 4 slothman 2003-05-18 21:14:06 UTC
This problem went away at one point when I reinstalled Red Hat 8.0
from scratch.  It has since returned after installing Red Hat 9 from
scratch.  Could this be caused by some sort of odd configuration problem?
Comment 5 michael.ruess 2003-05-23 12:50:47 UTC
In your sample Writer file you didn't use a DDE link to your Calc table.
What you did there was just inserting an embedded OLE object of the
Calc table. A DDE link is something quite different and AFAIK not
supported by Linux platforms.
Comment 6 slothman 2003-05-29 06:19:07 UTC
OK, I evidently became confused about the nature of the link.  I'm
still mystified by why it is that under some installations, the same
document will wind up with extra garbage whenever I use non-ASCII
characters, and under some installations it won't.  If I want to
examine the issues of the infrastructure behind locales and non-ASCII
characters under OpenOffice, where should I start?

Comment 7 michael.ruess 2003-09-09 16:02:35 UTC
MRU->OC: There 's a DDE-link inside the Calc-OLE, which seems to be
"causus cnaxus" ;-)
When inserting DDE link in a Calc document and using the attached .sxw
as source, you can see some formats and characters garbled. So no
Writer problem
Comment 8 oc 2003-09-22 14:13:28 UTC
Hi Niklas, please have a look
Comment 9 niklas.nebel 2003-09-24 18:57:13 UTC
Oliver, I don't see how this should happen.
Comment 10 slothman 2003-12-10 07:15:04 UTC
I think I figured it out-- problems using CPAN with Perl on Red Hat Linux and
the relevant fix (switching from LANG = en_US.utf-8 to LANG = en_US) made me try
it for  Sure enough, if I open my files using LANG=en_US.utf-8,
I get the weird symbols.  If I use LANG=en_US, the problem evaporates.
Comment 11 slothman 2004-05-06 07:42:08 UTC
The problem persists under under Fedora Core 1. 
LANG=en_US is fine, LANG=en_US.UTF-8 garbles non-ASCII characters.
Comment 12 frank 2004-06-04 11:37:17 UTC
Hi Niklas,

as discussed this one back to you.

It seems that DDE Links are sent encoded but would not be decoded as I've
understand our discussion. You've said we need a clear specification of the DDE

Comment 13 frank 2005-07-15 12:02:05 UTC
*** Issue 51603 has been marked as a duplicate of this issue. ***
Comment 14 frank 2005-07-20 15:18:50 UTC
*** Issue 51740 has been marked as a duplicate of this issue. ***
Comment 15 kyoshida 2005-09-19 03:51:56 UTC
Just for the record, the DDE server side code is located in

ScServerObject::GetData( ... )

while the DDE client side code is located in

ScDdeLink::DataChanged( ... )

Furthermore, there is a "fix" at least for Linux.  In the DDE client code
referenced above, there is this line:

  ScByteSequenceToString::GetString( aLinkStr, rValue, DDE_TXT_ENCODING );

which probably gets the string from the DDE server.  In this line, changing the
encoding from "DDE_TXT_ENCODING" to "gsl_getSystemTextEncoding()" solved this
problem at least for the Japanese encoding.  Tora also reported that doing the
same also solved it on the Japanese version of Windows.
Comment 16 kyoshida 2005-09-19 04:13:44 UTC
Just as a note, here is the link to MS's DDE documentation (thanks to Tora)

This page specifies that for a DDE transaction, a CP_WINANSI code page should be
used for non-multibyte character set, and CP_WINUNICODE for unicode character set.
Comment 17 frank 2006-06-26 13:58:08 UTC
*** Issue 66342 has been marked as a duplicate of this issue. ***
Comment 18 tora3 2006-11-11 17:21:51 UTC
This problem can be observed with OOo_2.0.4. 
This issue was firstly reported at the time of OOo 1.1.

At least, within the integrated, productive office suite, 
e.g. Calc to Calc, we should try to solve this issue. 

There are two different ways to link a cell or range across files.

Scenario A:

 This works.

 1. Create two empty spreadsheet. (1st and 2nd one)
 2. Fill a cell with a non-Western script in the 1st one.
 3. Move to the 2nd one by clicking the 2nd one's window.
 4. Type an equal mark to enter to edit mode.
 5. Click on the title bar of the window of the 1st one.
 6. Click on the cell in the 1st one prepared with the step 2. (*1)
 7. Click on the title bar of the window of the 2nd one.
 8. Type an Enter key to go out from the edit mode.

    You would see a non-Western text was correctly displayed.

  *1: If you select some cells, i.e. a range, type a Ctrl-Shift-Enter 
      in the step 8 to treat them as a matrix.

Scenario B:

 This does not works.

 1. Create two empty spreadsheet. (1st and 2nd one)
 2. Fill a cell with a non-Western script in the 1st one.
 3. Copy the cell.
 4. Move to the 2nd one by clicking the 2nd one's window.
 5. Edit - Paste Special with a check mark on the option "Link"

    You would find a non-Western text was displayed with garbage 
    characters unexpectedly.

Comment 19 frank 2007-01-29 15:55:24 UTC
*** Issue 72695 has been marked as a duplicate of this issue. ***
Comment 20 ooo 2007-03-08 16:43:00 UTC
*** Issue 73246 has been marked as a duplicate of this issue. ***
Comment 21 elmede 2007-04-05 00:28:50 UTC
Ok, to confirm this problem.

I can confirm as well that the problem appears when UTF-8 encoding is used as 
the system default.

I used to use es_MX as the locale and this problem never occured (I have a 
series of documents linked together with DDE Links) and I converted to UTF a 
couple months ago and today I revisited those documents to see them all 

The most ironic thing is that I converted to UTF-8 because of openoffice!

See bug #61732, when the locale is not UTF-8 enabled, Openoffice doesn't 
handle international characters in filenames! So I ran from one problem right 
into another.  And this one is quite disastrous.

I'm trying kohei's suggestion (patch in sc/source/core/tool/ddelink.cxx) but 
it will be a couple of hours more of compiling before I know if it works or 
not (it's easy to compile the patched sources, I'm running gentoo)

Anyway, i think this is a serious problem and it's hard for me to believe that 
it hasn't at least received a target milestone or even changed the status to 
confirmed (taking into account it's been active since 2003!! and with a lot of 

What can I help with??  Is there any way we can get this process moving?

Thanks for the great work... really... this is a great application (and as 
such it's supposed to have its glitches ;)
Comment 22 elmede 2007-04-05 21:16:17 UTC
Oh my gosh!! It works!!!!

It actually makes sense to get the system wide encoding (through 
gsl_getSystemTextEncoding), instead of using text encoding (through 

I definitely am not an openoffice developer or anything for saying that, but 
what I know is that it works!!

Ok, any chance this could be incorporated into openoffice so I don't have to 
be patching the sources everytime???  (I mean, I'm happy to do it if it's 
what's required to keep things working, but changing one line in the main 
trunk makes sense when it solves a problem like this one!)

Thanks, tora, kohei, and everyone for the great work!!
Comment 23 lohmaier 2007-05-24 12:21:47 UTC
please attach the patch

extended the summary to make it easier to find..
Comment 24 lohmaier 2007-05-24 12:22:19 UTC
*** Issue 65867 has been marked as a duplicate of this issue. ***
Comment 25 lohmaier 2007-05-24 12:23:02 UTC
*** Issue 77749 has been marked as a duplicate of this issue. ***
Comment 26 lohmaier 2007-05-24 12:25:23 UTC
*** Issue 27009 has been marked as a duplicate of this issue. ***
Comment 27 hagar_de_lest 2007-05-24 12:31:36 UTC
Note that as said in issue 65867, this is a Framework bug, not limited to
Comment 28 hagar_de_lest 2007-06-08 08:37:36 UTC
Confirmed on 2.2 en-US version with French language pack (official RPMs) under
Ubuntu Dapper, locale is fr_FR.UTF-8 :
When special characters are pasted as DDE link (either coming from Calc or
Writer) into Writer (or Calc), they're not correctly displayed, here is a sample
of the result :
€ -> €
£ -> £
¤ -> ¤
µ -> µ
$ -> $ (OK)
@ -> @ (OK)

Also reported here :
(under 2.0.2 but OS has not been given).

Also confirmed under Mac OS X 10.4.9 here (in French) :
Comment 29 elmede 2007-06-11 23:07:39 UTC
To cloph:

Sorry!! I actually don't have a patch by itself.  What I did was that I edited 
the file 


itself by replacing the word 




but I did all that manually.  Don't have a diff to apply with patch.. Would be 
more than willing to do that the only thing is I don't have any idea of how to 
do it :(  (I think I would type it in an editor but then It would be extremely 
probable that I would type it with errors on it)

Comment 30 elmede 2007-06-11 23:22:32 UTC
Created attachment 45821 [details]
Patch to file sc/source/core/tool/ddelink.cxx
Comment 31 elmede 2007-06-11 23:24:48 UTC
Well.. as with anything in this great linux world.  Put your money where your 
mouth is :)  (no matter how small this may be)

I've attached a patch that is FAAAAR from perfect.  It says "missing header 
for unified diff at line 3 of patch" but corrects the file with the command:

patch -p1 ddelink.cxx patch.ddelink

It has to be run from the directory where the file ddelink.cxx is located

Comments appreciated ;)

Comment 32 elmede 2007-06-19 03:23:41 UTC
Created attachment 46045 [details]
Corrected Patch to file sc/source/core/tool/ddelink.cxx
Comment 33 elmede 2007-06-19 03:26:02 UTC
hehe... Just as expected..

The previous patch didn't work at all.. I had spaces instead of tabs so the 
patch didn't get applied correctly..

I've just compiled 2.2.1 with the above patch which was 
applied, being in the directory of ddelink.cxx with

patch ddelink.cxx patch.ddelink -b

(The -b just for precaution, creating a backup) and everything worked 
alright..  Openoffice compiled without a hitch and dde links of special 
non-ascii characters work as expected..

If only someone with the right priviledges would erase the previous patch 
(which is wrong)


Comment 34 lohmaier 2007-06-22 18:55:15 UTC
Thanks for the patch, I change the issuetype accordingly, so it appears in the
developer's radar more prominently.

Unfortunately, IssueZilla doesn't allow deletin of attachments by
non-site-admins, and doesn't offer a way to flag attachments as obsolete or similar.
Comment 35 frank 2007-08-27 13:36:28 UTC
*** Issue 81049 has been marked as a duplicate of this issue. ***
Comment 36 frank 2007-08-27 13:37:55 UTC
Hi Niklas,

what's about 2.4 ?

Comment 37 ooo 2007-08-28 11:09:13 UTC
For completeness see also issue 15540 in Writer and for possible DDE scenarios

DDE encoding may need to be addressed OOo wide.
Comment 38 Mathias_Bauer 2007-09-11 12:01:04 UTC
As this is something that at touches Writer at least remotely I would be
interested to hear something about the status of this patch.

Is it rejected?
Will be take it?
Does it need some rework?

Depending on the answers to these questions either the target or the type of
this issue might need a change.
Comment 39 kami911 2007-09-20 19:40:54 UTC
I am suffering from this issue, are there any chance to get in the game?
Comment 40 rail_ooo 2008-02-21 22:13:29 UTC
Attached is another patch which fixes (in the same way) DDE encoding in SC and
SW. Of course we assume that source and target applications use the same
encoding (not hard coded cp1252 as now). This is the easiest way but it works in
most of cases (tested :) ).

BTW, can we mark issue 15540 as duplicate of this issue?
Comment 41 rail_ooo 2008-02-21 22:14:24 UTC
Created attachment 51643 [details]
Proposed patch
Comment 42 ooo 2008-02-25 11:34:09 UTC
Using gsl_getSystemTextEncoding() should indeed fix the most common DDE usage,
linking between applications on the same machine and user account. It may break
though reading from remote hosts and the other scenarios mentioned in

However, I think that having the common scenario fixed is more important than
corner cases, with one exception: DDE to services on remote hosts that deliver 
"real time" data in Windows-1252 or cp-850 encoding.

@mba, @nn: do we know of any remote host scenarios actively used by customers
that rely on encoding? I only remember one case on OS/2 that was about 12 years

I'll mark issue 15540 as a duplicate as you can't fix them independently and
this issue here has more details.
Comment 43 ooo 2008-02-25 11:35:46 UTC
*** Issue 15540 has been marked as a duplicate of this issue. ***
Comment 44 rail_ooo 2008-03-17 08:28:52 UTC
Any chance to retarget to 3.0?
Comment 45 Mathias_Bauer 2008-03-17 10:41:42 UTC
@er: I don't know any customer relying on such remote scenarios. But I'm not
sure if that tells us anything. ;-)
Comment 46 kpalagin 2008-04-22 13:25:30 UTC
So what is the decision - solve the problem or not?
Comment 47 perlhead 2008-09-17 17:50:46 UTC
I still see this issue, which was reported six years ago, in version 2.4.1 on
Ubuntu Hardy, LANG=en_US.UTF-8.

This is a serious issue, which makes OOo unsuitable for use in non-English
speaking environments where users must link spreadsheets containing text (which
one would assume is pretty common use case)!
Comment 48 omgs 2008-09-17 20:32:57 UTC
I can confirm that in ubuntu Hardy with locale "es_ES.UTF-8" ( 2.4.1),
doing a "Paste special" and link, the result is that I get bad encoding **using
different files**, but inside the same file, the encoding is ok. Sorry if this
last detail has already been supplied (I didn't fully read all past comments).

I wonder: do documents store the used encoding anywhere? I think that
relaying on the environment locale is not a good idea (if this the internal

Please fix this issue.
Comment 49 carreraj 2008-09-18 08:17:54 UTC
It happens also in:
 - OSX (2.4.1 and 3.0rc1)
 - Languaje: spanish

when doing a paste special->link from diferent file.
Comment 50 niklas.nebel 2008-09-19 18:34:54 UTC
CP_WINANSI stands for "default codepage", so using gsl_getSystemTextEncoding is
correct. On Windows systems in western Europe and America, this is MS_1252,
which we used before, so we don't break anything there. In other regions, it
seems unlikely that someone's relying on MS_1252 characters from some DDE server
that doesn't follow the rules.

If mba or os doesn't object to the Writer part, we can use this patch (except
that swdtflvr.cxx could use a temporary variable instead of the repeated
gsl_getSystemTextEncoding calls).
Comment 51 Oliver Specht 2008-09-22 14:41:46 UTC
I aggree to the changes in sw (with temporary variable) 
Comment 52 niklas.nebel 2008-10-28 13:49:36 UTC
I added the last patch (plus the temporary variable) to CWS "calc47".
Comment 53 pmike 2008-10-30 07:50:29 UTC
I would like to say: "Thank you!" all those who worked on this issue
Comment 54 niklas.nebel 2008-12-04 15:45:49 UTC
Reassigning to QA for verification
Comment 55 oc 2008-12-09 14:23:21 UTC
verified in internal build cws_calc47
Comment 56 andisl 2009-01-30 10:07:09 UTC
I tested DDE link in DEV300_m40 built (Windows XP SP2) and the problem is still
there. Instead of āāāā is see ????.
Comment 57 vladimir_hitekschool 2009-04-01 18:51:56 UTC
As far as Issue 9709 concerned in version OOo-dev 3.1 .0 (OOO310m7 Build:9393) 
for Windows XP the problem seems to solve for writer, but for calc the problem 
still remains. See attachments.
Comment 58 vladimir_hitekschool 2009-04-01 18:53:42 UTC
Created attachment 61342 [details]
Writer OOo-dev 3.1 .0 (OOO310m7 Build:9393) for Windows XP
Comment 59 vladimir_hitekschool 2009-04-01 18:55:58 UTC
Created attachment 61343 [details]
Calc OOo-dev 3.1 .0 (OOO310m7 Build:9393) for Windows XP
Comment 60 kpalagin 2009-04-02 11:17:11 UTC
please provide sample .ods, as I can't repro your scenario using either m44 or 
Comment 61 thorsten.ziehm 2009-07-20 14:40:37 UTC
This issue is closed automatically and wasn't rechecked in a current version of
OOo. This fixed issue should be integrated in OOo since more than half a year.
If you think this issue isn't fixed in a current version (OOo 3.1), please
reopen it and change the field 'Target Milestone' accordingly.

If you want to download a current version of OOo =>
If you want to know more about the handling of fixed/verified issues =>
Comment 62 thorsten.ziehm 2009-07-20 15:35:56 UTC
Sorry this issue was wrongly closed. This issue will be reopened automatically.
And will be set after that back to fixed/verified.
Comment 63 thorsten.ziehm 2009-07-20 15:40:14 UTC
Set to state 'fixed'.
Comment 64 thorsten.ziehm 2009-07-20 15:44:28 UTC
Set back to state 'verified/fixed'.

Again. Sorry for the mass of mails.
Comment 65 thorsten.ziehm 2010-02-22 14:48:34 UTC
This issue is closed automatically. It should be fixed in a version with is
available for longer than half a year (OOo 3.1). If you think this issue isn't
fixed in the current version (OOo 3.2) please reopen it. But then please pay
attention about the field 'target milestone'.
The closure was approved by the Release Status Meeting at 22nd of February 2010
and it is based on the issue handling guideline for fixed/verified issues  :