Issue 13212

Created attachment 5541 [details]
Table with czech chars

Created attachment 5542 [details]
Clipboard format "Enhanced Metafile" is OK

Created attachment 5543 [details]
Clipboard format "Picture" is wrong

Hi,

could you please attach a document that uses such chararcters ?

It makes work much easier.

Thanks

Frank

Created attachment 5544 [details]
Calc document for testing copy&paste

Hi Sven,

as discussed this one is for you.

Frank

SJ->HDU: We are converting GDIMetafiles into EMF files if pasting into
other applications on windows. I found out that the problem already
happened if recording our own GDI metafile format.

I changed the target, because I think that this issue is really
important and should be fixed for 6.1 Beta2.

Could you please have a look at it and provide this Issue to the
proper person.

HDU->SJ: have a look at the MetaTextArrayAction::Write() method and especially 
  the line with WriteByteString( maUnicodeStr, pData->meActualCharSet :-) 
 

This bug needs to be fixed, I will start just now.

This bug has been fixed now, it will be available in OOo1.1 Beta2.

The fix takes place in cws[mav4]->vcl/source/gdi/metaact.cxx

Thanks for providing this bug.

SJ->FST: This bug is now ready to be verified on cws[mav4].

Restoring fixed state

Verified in internal build mav04

Found integrated in srx644m13

Still the bug for Picture clipboard format in OOo1.1Beta2.

Sorry, i can't reproduce it. It works fine.
Build Id: 8600

Closed fixed

Created attachment 6649 [details]
clipboard format Picture from build 8600

I created new attachment with screenshot from clipbrd.exe, data was
copied from English OOo11Beta2. 
Can you provide screeshot like this from your windows, if this runs
correctly for you?

part of setup.ini:
ProfileItem gid_Profileitem_Bootstrap_Buildid
	ModuleID	 = gid_Module_Root;
	ProfileID	 = gid_Profile_Bootstrap_Ini;
	Section		 = "Bootstrap";
	Key			 = "buildid";
	Value		 = "644(Build:8600)";
	Order		 = 6;
End

It's the same version and build ID.

I've attached a screenshot of the clipboard viewer on my system.

Frank

Created attachment 6650 [details]
Screenshot showing correct behaviour

I have the same results as kwart on OO1.1beta2 on windows 2000
(Service Pack 2).

I have tested it on two computers (but with the same configuration)
with original OO1.1beta2 and also on some czech localized builds of
OO1.1beta2 and I have obtained same results as kwart in attachment
(id=6649) everytime!

From clipbrd.exe - there is possible to save content of the clipboard
(with all clipboard formats) and later open it in clipbrd.exe.

TO fst: Can you please put your saved clipboard as attachement, so we
can compare it on our computers?

Created attachment 6669 [details]
The clipboard content of my W2k SP3

It's really OK in your clipboard.
I have also Win2K SP3 and the bug is there :(.
Has the file vcl644mi.dll from your installation 1,884,226 B?
(MD5sum: a6fd0d576ab9fa16dea074fbdb1628b7 *vcl644mi.dll)

Yeep,

Byte count and md5sum are the same for vcl644mi.dll

Frank

I've get it.
My locale and default language settings was set to Czech. If I change
it to English (US) it's OK.
Probably default language settings for system is the main problem. I
have WinNT4 with configuration [default regional settings:Czech;
regional settings: English] on second machine and bug is also there.

Can you correct also this bug?

Yes kwart has true. The same for me on win2k Service Pack 2.

The bug depends on default locale. Not on current locale.

1) When I have in Control panels-Regional Option:
  Your locale(location):
    Czech

  Language settings for your system:
    Central Europe (defalt)
    Wester Europe and United States

BUG happened

2) When I change this to (and restart computer):
  Your locale(location):
    Czech

  Language settings for your system:
    Central Europe
    Wester Europe and United States (Defalt)
Everyting seems O.K.

Hi,

finally we found out what the problem is. Sorry to tell you, but we
can't fix it. The problem is that the picture view is an WMF format.
WMF is not capable to handle unicode characters. So this is a problem
of the underlying picture format. 

What we have fixed is the ability to use the other formats in
conjunction with metafiles.

Sorry for no better reply.

Frank

closed fixed