Copy/Paste problems when contains non-ascii characters

Copy/Paste problems when contains non-ascii characters

[Jay Smith]

Hi,

My copy/paste behavior in MOZILLA running on RedHat 8 LINUX has gone from 
bad to worse when I upgraded the Mozilla from 1.2.x to 1.4.

Important: The Mozilla is LINUX Mozilla running on an RH8 server.  I am 
sitting at a Windows 95 PC, using Cygwin/XFree86 to run an X session on the 
PC.  I am sitting at a PC, not at a Linux box.  (Most people don't get this 
and thus reply using wrong assumptions.)

WHEN RUNNING Linux Mozilla ON PC USING CYGWIN:

(old) MOZ 1.2.x: When I copied text that contained a non-ascii typical 
European or Scandinavian character from an existing email and PASTED INTO A 
MOZILLA MAIL COMPOSE window, the text up to, but NOT including, the 
character would copy AND PASTE. That was bad, but at least you got 
something (the text before the character).

(new) MOZ 1.4: However, now, if the copy contains such a character, NOTHING 
gets pasted into A MOZILLA MAIL COMPOSE window.  It changed from partial to 
nothing.

I AM still able to paste full and properly into windows applications from 
Mozilla, including such common European and Scandinvian characters.

Because there has been no change to the Cygwin installation on this PC, I
don't think the *change* in the problem is related to that.  However, the 
root of the problem seems to be related to Cygwin.

By contrast, IF I AM WORKING DIRECTLY/PHYSICALLY ON THE LINUX SERVER:

Mozilla 1.2.x or 1.4: I *CAN* fully and properly cut/paste the very same text.

MY ENVIRONMENT IS:

Server: Red Hat Linux 8

Workstation: Windows 95 running Cygwin ....
(I think these are the version numbers of what I have installed; they were 
as of April 2003 and I don't think I have installed any new Cygwin stuff on 
this machine since then -- but I don't know how to find out what versions I 
am running. How do I?)
   XFree86-base     4.2.0-1
          -lib      4.2.0-5
          -xserv    4.2.0-28
          -xwinclip 4.2.0-8

Jay
-- 
Jay Smith

e-mail: Jay@JaySmith.com  mailto:Jay@JaySmith.com
website: http://www.JaySmith.com

Jay Smith & Associates
P.O. Box 650
Snow Camp, NC  27349  USA

Phone: Int+US+336-376-9991
Toll-Free Phone in US & Canada:
	1-800-447-8267
Fax: Int+US+336-376-6750

Re: Copy/Paste problems when contains non-ascii characters

[Harold L Hunt II]

Jay,

Your problem is that you are using Windows 95, which does not natively 
support unicode text.  There is support in Cygwin/XFree86 for converting 
characters to unicode and back, but it only works on NT-based platforms 
(NT 4.0, Windows 2000, Windows XP, Windows Server 2003).

The Microsoft Layer for Unicode on Windows 95/98/Me Systems should allow 
the support to work properly, but we would have to change the unicode 
support detection slightly for this to take effect.  Have you installed 
the unicode support for Windows 95?  More information and a link to 
download are here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devnotes/winprog/microsoft_layer_for_unicode_on_windows_95_98_me_systems.asp

Or, the tiny url to the same thing:

http://tinyurl.com/qo9n


Hmm... just did some more checking... using the Layer for Unicode 
support will not be trivial.  Kensuke may be interested in it as an 
alternative to using libiconv on Windows 95/98/Me.

As for why you text copying is truncated vs. not appearing at all, I 
suspect that Mozilla 1.2.x to 1.4 changed the format of some clipboard 
data from plain text to INCR.  But that would only make sense if you 
have only tried this with the versions of XFree86-xserv that don't crash 
when they see an INCR clipboard format.  If you didn't try this until 
recently, then that would explain your problem.  You should at least be 
thankful that XWin.exe doesn't core dump like it used to in these cases.

In summary, your problem is known, it isn't trivial to solve, and the 
change from Mozilla 1.2.x to 1.4 is due to a change that they made, not 
something that we did.  Also, your issue is already known to be not an 
issue on NT-based platforms, so the Microsoft answer to this problem 
would be "The Cygwin/XFree86 has identified this to be a problem with 
the products listed above.", with the idea being that they might fix it 
or they might not, but perhaps you should consider upgrading to a more 
recent version of Windows.  In other words, you are more likely to get 
your problem fixed by spending $200 of your own money upgrading to 
Windows XP, versus me spending $2000 of my time to cobble together a fix 
for Windows 95/98/Me.  That's just being honest.

Thanks for testing,

Harold

Jay Smith wrote:
> Hi,
> 
> My copy/paste behavior in MOZILLA running on RedHat 8 LINUX has gone 
> from bad to worse when I upgraded the Mozilla from 1.2.x to 1.4.
> 
> Important: The Mozilla is LINUX Mozilla running on an RH8 server.  I am 
> sitting at a Windows 95 PC, using Cygwin/XFree86 to run an X session on 
> the PC.  I am sitting at a PC, not at a Linux box.  (Most people don't 
> get this and thus reply using wrong assumptions.)
> 
> WHEN RUNNING Linux Mozilla ON PC USING CYGWIN:
> 
> (old) MOZ 1.2.x: When I copied text that contained a non-ascii typical 
> European or Scandinavian character from an existing email and PASTED 
> INTO A MOZILLA MAIL COMPOSE window, the text up to, but NOT including, 
> the character would copy AND PASTE. That was bad, but at least you got 
> something (the text before the character).
> 
> (new) MOZ 1.4: However, now, if the copy contains such a character, 
> NOTHING gets pasted into A MOZILLA MAIL COMPOSE window.  It changed from 
> partial to nothing.
> 
> I AM still able to paste full and properly into windows applications 
> from Mozilla, including such common European and Scandinvian characters.
> 
> Because there has been no change to the Cygwin installation on this PC, I
> don't think the *change* in the problem is related to that.  However, 
> the root of the problem seems to be related to Cygwin.
> 
> By contrast, IF I AM WORKING DIRECTLY/PHYSICALLY ON THE LINUX SERVER:
> 
> Mozilla 1.2.x or 1.4: I *CAN* fully and properly cut/paste the very same 
> text.
> 
> MY ENVIRONMENT IS:
> 
> Server: Red Hat Linux 8
> 
> Workstation: Windows 95 running Cygwin ....
> (I think these are the version numbers of what I have installed; they 
> were as of April 2003 and I don't think I have installed any new Cygwin 
> stuff on this machine since then -- but I don't know how to find out 
> what versions I am running. How do I?)
>   XFree86-base     4.2.0-1
>          -lib      4.2.0-5
>          -xserv    4.2.0-28
>          -xwinclip 4.2.0-8
> 
> Jay

[PATCH] Copy/Paste non-ascii characters

[Kensuke Matsuzaki]

[-- Attachment #1: Type: text/plain, Size: 912 bytes --]

Jay,

Perhaps this patch enable XWin to copy/paste non-ascii characters
even if Windows does't support Unicode (95/98/Me).
LANG environment variable and Windows locale must be same.
I added -nounicodeclipboard option, I tested using this on XP.
But I don't have 95/98/Me.

And it seems tha libX11 has some CTEXT convertion bug, I attach
patch that based on TAKABE's work.
http://www.ff.iij4u.or.jp/~t-takabe/xf410_xim_fix.diff

By the way, nls/locale.alias has alias somethig like
"Arabic_Egypt.1256". Can we use that?
If so, we no longer need LANG environment variable.
We can get it following code.

  char pszCountry[128];
  char pszLanguage[128];
  int nAcp = GetACP ();
  
  GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGCOUNTRY, pszCountry, 128);
  GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGLANGUAGE, pszLanguage, 128);

  printf ("%s_%s.%d\n", pszLanguage, pszCountry, nAcp);

Kensuke Matsuzaki

[-- Attachment #2: clipboard_mb.diff --]
[-- Type: application/octet-stream, Size: 11109 bytes --]

diff -rub xwin-20031006-2120/InitOutput.c xwin/InitOutput.c
--- xwin-20031006-2120/InitOutput.c	Sat Sep 20 14:58:07 2003
+++ xwin/InitOutput.c	Sat Oct 11 09:57:16 2003
@@ -55,6 +55,7 @@
 Bool		g_fCalledSetLocale = FALSE;
 Bool		g_fCalledXInitThreads = FALSE;
 const char *	g_pszQueryHost = NULL;
+Bool		g_fUnicodeClipboard = TRUE;
 
 
 /*
@@ -365,6 +366,9 @@
 
   ErrorF ("-keyboard\n"
 	  "\tSpecify a keyboard device from the configuration file.\n");
+
+  ErrorF ("-nounicodeclipboard\n"
+	  "\tDo not use Unicode clipboard even if NT-based platform.\n");
 }
 
 
@@ -1221,6 +1225,16 @@
       CHECK_ARGS (1);
       g_cmdline.keyboard = argv[++i];
       return 2;
+    }
+
+  /*
+   * Look for the '-nounicodeclipboard' argument
+   */
+  if (IS_OPTION ("-nounicodeclipboard"))
+    {
+      g_fUnicodeClipboard = FALSE;
+      /* Indicate that we have processed the argument */
+      return 1;
     }
 
   return 0;
diff -rub xwin-20031006-2120/winclipboardthread.c xwin/winclipboardthread.c
--- xwin-20031006-2120/winclipboardthread.c	Sun Oct  5 03:49:23 2003
+++ xwin/winclipboardthread.c	Sat Oct 11 09:57:44 2003
@@ -36,6 +36,7 @@
  */
 
 extern Bool g_fCalledSetLocale;
+extern Bool g_fUnicodeClipboard;
 
 
 /*
@@ -105,10 +106,10 @@
   ErrorF ("winClipboardProc - pthread_mutex_lock () returned.\n");
 
   /* Do we have Unicode support? */
-  fUnicodeSupport = winClipboardDetectUnicodeSupport ();
+  fUnicodeSupport = g_fUnicodeClipboard && winClipboardDetectUnicodeSupport ();
 
   /* Set the current locale?  What does this do? */
-  if (fUnicodeSupport && !g_fCalledSetLocale)
+  if (!g_fCalledSetLocale)
     {
       ErrorF ("winClipboardProc - Calling setlocale ()\n");
       if (!setlocale (LC_ALL, ""))
diff -rub xwin-20031006-2120/winclipboardxevents.c xwin/winclipboardxevents.c
--- xwin-20031006-2120/winclipboardxevents.c	Tue Oct  7 10:18:22 2003
+++ xwin/winclipboardxevents.c	Sat Oct 11 09:48:37 2003
@@ -61,8 +61,8 @@
   HGLOBAL		hGlobal;
   Bool			fReturn = TRUE;
   XICCEncodingStyle	xiccesStyle;
-  int			iUTF8;
-  char			*pszUTF8 = NULL;
+  int			iConvertDataLen = 0;
+  char			*pszConvertData = NULL;
   char			*pszTextList[2];
   int			iCount;
   char			**ppszTextList = NULL;
@@ -253,7 +253,7 @@
 	  /* Convert the Unicode string to UTF8 (MBCS) */
 	  if (fUnicodeSupport)
 	    {
-	      iUTF8 = WideCharToMultiByte (CP_UTF8,
+	      iConvertDataLen = WideCharToMultiByte (CP_UTF8,
 					   0,
 					   (LPCWSTR)pszGlobalData,
 					   -1,
@@ -261,48 +261,59 @@
 					   0,
 					   NULL,
 					   NULL);
-	      pszUTF8 = (char *) malloc (iUTF8); /* Don't need +1 */
+	      pszConvertData = (char *) malloc (iConvertDataLen); /* Don't need +1 */
 	      WideCharToMultiByte (CP_UTF8,
 				   0,
 				   (LPCWSTR)pszGlobalData,
 				   -1,
-				   pszUTF8,
-				   iUTF8,
+				   pszConvertData,
+				   iConvertDataLen,
 				   NULL,
 				   NULL);
 	    }
+	  else
+	    {
+	      pszConvertData = strdup (pszGlobalData);
+	      iConvertDataLen = strlen (pszConvertData) + 1;
+	    }
 
 	  /* Convert DOS string to UNIX string */
-	  if (fUnicodeSupport)
-	    {
-	      winClipboardDOStoUNIX (pszUTF8, strlen (pszUTF8));
+	  winClipboardDOStoUNIX (pszConvertData, strlen (pszConvertData));
 
 	      /* Setup our text list */
-	      pszTextList[0] = pszUTF8;
+	  pszTextList[0] = pszConvertData;
 	      pszTextList[1] = NULL;
 	      
 	      /* Initialize the text property */
 	      xtpText.value = NULL;
 	      
 	      /* Create the text property from the text list */
+	  if (fUnicodeSupport)
+	    {
 	      iReturn = Xutf8TextListToTextProperty (pDisplay,
 						     pszTextList,
 						     1,
 						     xiccesStyle,
 						     &xtpText);
+	    }
+	  else
+	    {
+	      iReturn = XmbTextListToTextProperty (pDisplay,
+						   pszTextList,
+						   1,
+						   xiccesStyle,
+						   &xtpText);
+	    }
 	      if (iReturn == XNoMemory || iReturn == XLocaleNotSupported)
 		{
 		  ErrorF ("winClipboardFlushXEvents - SelectionRequest - "
-			  "Xutf8TextListToTextProperty failed: %d\n",
+		      "X*TextListToTextProperty failed: %d\n",
 			  iReturn);
 		  exit(1);
 		}
 	      
-	      /* Free the UTF8 string */
-	      free (pszUTF8);
-	    }
-	  else
-	    winClipboardDOStoUNIX (pszGlobalData, strlen (pszGlobalData));
+	  /* Free the converted string */
+	  free (pszConvertData);
 
 	  /*
 	   * FIXME: Pass pszGlobalData and strlen (pszGlobalData(
@@ -311,7 +322,6 @@
 	   */
 
 	  /* Copy the clipboard text to the requesting window */
-	  if (fUnicodeSupport)
 	    iReturn = XChangeProperty (pDisplay,
 				       event.xselectionrequest.requestor,
 				       event.xselectionrequest.property,
@@ -320,15 +330,6 @@
 				       PropModeReplace,
 				       xtpText.value,
 				       xtpText.nitems);
-	  else
-	    iReturn = XChangeProperty (pDisplay,
-				       event.xselectionrequest.requestor,
-				       event.xselectionrequest.property,
-				       event.xselectionrequest.target,
-				       8,
-				       PropModeReplace,
-				       pszGlobalData,
-				       strlen (pszGlobalData));
 	  if (iReturn == BadAlloc || iReturn == BadAtom
 	      || iReturn == BadMatch || iReturn == BadValue
 	      || iReturn == BadWindow)
@@ -345,11 +346,8 @@
 	  CloseClipboard ();
 
 	  /* FIXME: Don't clean up on 1 byte. */
-	  if (fUnicodeSupport)
-	    {
 	      XFree (xtpText.value);
 	      xtpText.value = NULL;
-	    }
 
 	  /* Setup selection notify event */
 	  eventSelection.type = SelectionNotify;
@@ -410,7 +408,6 @@
 	   * What are we doing here?
 	   *
 	   */
-	  if (fUnicodeSupport)
 	    {
 	      if (event.xselection.property == None)
 		{
@@ -467,7 +464,6 @@
 	    }
 
 	  /* Retrieve the size of the stored data */
-	  if (fUnicodeSupport)
 	    iReturn = XGetWindowProperty (pDisplay,
 					  iWindow,
 					  atomLocalProperty,
@@ -480,19 +476,6 @@
 					  &xtpText.nitems,
 					  &ulReturnBytesLeft,
 					  &xtpText.value);
-	  else
-	    iReturn = XGetWindowProperty (pDisplay,
-					  iWindow,
-					  atomLocalProperty,
-					  0,
-					  0, /* Don't get data, just size */
-					  False,
-					  AnyPropertyType,
-					  &atomReturnType,
-					  &iReturnFormat,
-					  &ulReturnItems,
-					  &ulReturnBytesLeft,
-					  &pszReturnData);
 	  if (iReturn != Success)
 	    {
 	      ErrorF ("winClipboardFlushXEvents - SelectionNotify - "
@@ -501,16 +484,11 @@
 	    }
 
 #if 0
-	  if (fUnicodeSupport)
 	    ErrorF ("SelectionNotify - returned data %d left %d\n",
 		    xtpText.nitems, ulReturnBytesLeft);
-	  else
-	    ErrorF ("SelectionNotify - returned data %d left %d\n",
-		    ulReturnItems, ulReturnBytesLeft);
 #endif
 
 	  /* Request the selection data */
-	  if (fUnicodeSupport)
 	    iReturn = XGetWindowProperty (pDisplay,
 					  iWindow,
 					  atomLocalProperty,
@@ -523,19 +501,6 @@
 					  &xtpText.nitems,
 					  &ulReturnBytesLeft,
 					  &xtpText.value);
-	  else
-	    iReturn = XGetWindowProperty (pDisplay,
-					  iWindow,
-					  atomLocalProperty,
-					  0,
-					  ulReturnBytesLeft,
-					  False,
-					  AnyPropertyType,
-					  &atomReturnType,
-					  &iReturnFormat,
-					  &ulReturnItems,
-					  &ulReturnBytesLeft,
-					  &pszReturnData);
 	  if (iReturn != Success)
 	    {
 	      ErrorF ("winClipboardFlushXEvents - SelectionNotify - "
@@ -543,9 +508,8 @@
 	      pthread_exit (NULL);
 	    }
 
-	  if (fUnicodeSupport)
-	    {
 #if 0
+	    {
 	      char		*pszAtomName = NULL;
 
 	      ErrorF ("SelectionNotify - returned data %d left %d\n",
@@ -555,13 +519,24 @@
 	      ErrorF ("Notify atom name %s\n", pszAtomName);
 	      XFree (pszAtomName);
 	      pszAtomName = NULL;
+	    }
 #endif
 	      
+	  if (fUnicodeSupport)
+	    {
 	      /* Convert the text property to a text list */
 	      iReturn = Xutf8TextPropertyToTextList (pDisplay,
 						     &xtpText,
 						     &ppszTextList,
 						     &iCount);
+	    }
+	  else
+	    {
+	      iReturn = XmbTextPropertyToTextList (pDisplay,
+						   &xtpText,
+						   &ppszTextList,
+						   &iCount);
+	    }
 	      if (iReturn == Success || iReturn > 0)
 		{
 		  /* Conversion succeeded or some unconvertible characters */
@@ -581,7 +556,7 @@
 		  else
 		    {
 		      ErrorF ("winClipboardFlushXEvents - SelectionNotify - "
-			      "Xutf8TextPropertyToTextList list_return is NULL\n");
+			      "X*TextPropertyToTextList list_return is NULL\n");
 		      pszReturnData = malloc (1);
 		      pszReturnData[0] = '\0';
 		    }
@@ -607,7 +582,6 @@
 	      /* Free the data returned from XGetWindowProperty */
 	      XFreeStringList (ppszTextList);
 	      XFree (xtpText.value);
-	    }
 	      
 	  /* Convert the X clipboard string to DOS format */
 	  winClipboardUNIXtoDOS (&pszReturnData, strlen (pszReturnData));
@@ -634,6 +608,11 @@
 				   pwszUnicodeStr,
 				   iUnicodeLen);
 	    }
+	  else
+	    {
+	      pszConvertData = strdup (pszReturnData);
+	      iConvertDataLen = strlen (pszConvertData) + 1;
+	    }
 
 	  /* Access the Windows clipboard */
 	  if (!OpenClipboard (hwnd))
@@ -656,7 +635,7 @@
 	    hGlobal = GlobalAlloc (GMEM_MOVEABLE,
 				   sizeof (wchar_t) * (iUnicodeLen + 1));
 	  else
-	    hGlobal = GlobalAlloc (GMEM_MOVEABLE, strlen (pszReturnData) + 1);
+	    hGlobal = GlobalAlloc (GMEM_MOVEABLE, iConvertDataLen);
 
 	  /* Obtain a pointer to the global memory */
 	  pszGlobalData = GlobalLock (hGlobal);
@@ -673,7 +652,7 @@
 		    pwszUnicodeStr,
 		    sizeof (wchar_t) * (iUnicodeLen + 1));
 	  else
-	    strcpy (pszGlobalData, pszReturnData);
+	    strcpy (pszGlobalData, pszConvertData);
 
 	  /* Free the data returned from XGetWindowProperty */
 	  if (fUnicodeSupport)
@@ -683,8 +662,8 @@
 	    }
 	  else
 	    {
-	      XFree (pszReturnData);
-	      pszReturnData = NULL;
+	      free (pszConvertData);
+	      pszConvertData = NULL;
 	    }
 
 	  /* Release the pointer to the global memory */
diff -rub xwin-20031006-2120/winmultiwindowwm.c xwin/winmultiwindowwm.c
--- xwin-20031006-2120/winmultiwindowwm.c	Sun Oct  5 03:52:22 2003
+++ xwin/winmultiwindowwm.c	Mon Oct 13 07:52:38 2003
@@ -399,10 +399,10 @@
       /* */
       if (nNum && ppList && *ppList)
 	{
-	  XFree (xtpName.value);
 	  *ppName = strdup (*ppList);
 	  XFreeStringList (ppList);
 	}
+      XFree (xtpName.value);
 
 #if CYGMULTIWINDOW_DEBUG
       ErrorF ("GetWindowName - %s %s\n",
@@ -974,16 +974,12 @@
  * winInitMultiWindowWM - 
  */
 
-Bool
-winClipboardDetectUnicodeSupport ();
-
 static void
 winInitMultiWindowWM (WMInfoPtr pWMInfo, WMProcArgPtr pProcArg)
 {
   int                   iRetries = 0;
   char			pszDisplay[512];
   int			iReturn;
-  Bool			fUnicodeSupport;
 
   ErrorF ("winInitMultiWindowWM - Hello\n");
 
@@ -1007,11 +1003,8 @@
 
   ErrorF ("winInitMultiWindowWM - pthread_mutex_lock () returned.\n");
 
-  /* Do we have Unicode support? */
-  fUnicodeSupport = winClipboardDetectUnicodeSupport ();
-
   /* Set the current locale?  What does this do? */
-  if (fUnicodeSupport && !g_fCalledSetLocale)
+  if (!g_fCalledSetLocale)
     {
       ErrorF ("winInitMultiWindowWM - Calling setlocale ()\n");
       if (!setlocale (LC_ALL, ""))

[-- Attachment #3: X11.diff --]
[-- Type: application/octet-stream, Size: 5448 bytes --]

Index: X11//lcEuc.c
===================================================================
RCS file: /cvsroot/xoncygwin/xc/lib/X11/lcEuc.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 lcEuc.c
--- X11//lcEuc.c	3 Jun 2003 11:03:57 -0000	1.1.1.2
+++ X11//lcEuc.c	13 Oct 2003 01:19:27 -0000
@@ -834,6 +834,8 @@
     wchar_t wch;
     Ulong wc_encoding;
     CTData ctdp = ctdata;
+    CTData GL_ctdp = ctdp;/* GL ctdp save */
+    CTData GR_ctdp = ctdp;/* GR ctdp save */
     Bool save_outbuf = True;
     /* If outbufptr is NULL, doen't save output, but just counts
        a length to hold the output */
@@ -842,6 +844,18 @@
     for (length = ctdata[Ascii].length; *from_left > 0; (*from_left) -= length)
     {
 	ct_type = CT_STD;
+	/* change GL/GR charset */
+	if(ctdp->side == XlcGR && isleftside(*inbufptr)){
+	    /* select GL side */
+	    ctdp = GL_ctdp;
+	    length = ctdp->length;
+	    ct_type = ctdp->ct_type;
+	}else if(ctdp->side == XlcGL && isrightside(*inbufptr)){
+	    /* select GR side */
+	    ctdp = GR_ctdp;
+	    length = ctdp->length;
+	    ct_type = ctdp->ct_type;
+	}
 	if (*inbufptr == '\033' || *inbufptr == (char)'\233') {
 	    for (ctdp = ctdata; ctdp <= ctd_endp ; ctdp++) {
 
@@ -858,6 +872,11 @@
 			}
 		    }
 		    ct_type = ctdp->ct_type;
+		    if(ctdp->side == XlcGL){
+			GL_ctdp = ctdp; /* save GL ctdp */
+		    }else{
+			GR_ctdp = ctdp; /* save GR ctdp */
+		    }
 		    break;
 		}
 	    }
@@ -1093,6 +1112,8 @@
     unsigned int ct_seglen = 0;
     Uchar ct_type = 0;
     CTData ctdp = &ctdata[0];	/* default */
+    CTData GL_ctdp = ctdp;	/* GL ctdp save */
+    CTData GR_ctdp = ctdp;	/* GR ctdp save */
     Bool save_outbuf = True;
     /* If outbufptr is NULL, doen't save output, but just counts
        a length to hold the output */
@@ -1101,6 +1122,18 @@
     for (length = ctdata[Ascii].length; *from_left > 0; (*from_left) -= length)
     {
 	ct_type = CT_STD;
+	/* change GL/GR charset */
+	if(ctdp->side == XlcGR && isleftside(*inbufptr)){
+	    /* select GL side */
+	    ctdp = GL_ctdp;
+	    length = ctdp->length;
+	    ct_type = ctdp->ct_type;
+	}else if(ctdp->side == XlcGL && isrightside(*inbufptr)){
+	    /* select GR side */
+	    ctdp = GR_ctdp;
+	    length = ctdp->length;
+	    ct_type = ctdp->ct_type;
+	}
 	if (*inbufptr == '\033' || *inbufptr == (char)'\233') {
 
 	    for (ctdp = ctdata; ctdp <= ctd_endp ; ctdp++) {
@@ -1118,6 +1151,11 @@
 			}
 		    }
 		    ct_type = ctdp->ct_type;
+		    if(ctdp->side == XlcGL){
+			GL_ctdp = ctdp; /* save GL ctdp */
+		    }else{
+			GR_ctdp = ctdp; /* save GR ctdp */
+		    }
 		    break;
 		}
 	    }
Index: X11//lcSjis.c
===================================================================
RCS file: /cvsroot/xoncygwin/xc/lib/X11/lcSjis.c,v
retrieving revision 1.1.1.2
diff -u -r1.1.1.2 lcSjis.c
--- X11//lcSjis.c	3 Jun 2003 11:03:58 -0000	1.1.1.2
+++ X11//lcSjis.c	13 Oct 2003 01:19:33 -0000
@@ -991,6 +991,13 @@
 	    ct_state.GR_charset = charset;
 	else if (charset->side == XlcGL)
 	    ct_state.GL_charset = charset;
+
+	if (charset == ct_state.GR_charset) {
+	    clen = charset->length;
+	    do {
+		(*(Uchar *)(ctptr-clen)) = BIT8ON(*(Uchar *)(ctptr-clen));
+	    } while (--clen); 
+	}
     }
 
     *to = (XPointer)ctptr;
@@ -1147,6 +1154,8 @@
     unsigned int ct_seglen = 0;
     Uchar ct_type;
     CTData ctdp = ctdata;	/* default */
+    CTData GL_ctdp = ctdp;/* GL ctdp save */
+    CTData GR_ctdp = ctdp;/* GR ctdp save */
 
     if (*from_left > *to_left)
 	*from_left = *to_left;
@@ -1154,6 +1163,18 @@
     for (length = ctdata[Ascii].length; *from_left > 0 ; (*from_left) -= length)
     {
 	ct_type = CT_STD;
+	/* change GL/GR charset */
+	if(ctdp->side == XlcGR && isleftside(*inbufptr)){
+	    /* select GL side */
+	    ctdp = GL_ctdp;
+	    length = ctdp->length;
+	    ct_type = ctdp->ct_type;
+	}else if(ctdp->side == XlcGL && isrightside(*inbufptr)){
+	    /* select GR side */
+	    ctdp = GR_ctdp;
+	    length = ctdp->length;
+	    ct_type = ctdp->ct_type;
+	}
 	if (*inbufptr == '\033' || *inbufptr == (char)'\233') {
 
 	    for (ctdp = ctdata; ctdp <= ctd_endp ; ctdp++) {
@@ -1171,6 +1192,11 @@
 			}
 		    }
 		    ct_type = ctdp->ct_type;
+		    if(ctdp->side == XlcGL){
+			GL_ctdp = ctdp; /* save GL ctdp */
+		    }else{
+			GR_ctdp = ctdp; /* save GR ctdp */
+		    }
 		    break;
 		}
 	    }
@@ -1265,6 +1291,8 @@
     wchar_t wch;
     Ulong wc_encoding;
     CTData ctdp = ctdata;
+    CTData GL_ctdp = ctdp;/* GL ctdp save */
+    CTData GR_ctdp = ctdp;/* GR ctdp save */
 
     if (*from_left > *to_left)
 	*from_left = *to_left;
@@ -1272,6 +1300,18 @@
     for (length = ctdata[Ascii].length; *from_left > 0; (*from_left) -= length )
     {
 	ct_type = CT_STD;
+	/* change GL/GR charset */
+	if(ctdp->side == XlcGR && isleftside(*inbufptr)){
+	    /* select GL side */
+	    ctdp = GL_ctdp;
+	    length = ctdp->length;
+	    ct_type = ctdp->ct_type;
+	}else if(ctdp->side == XlcGL && isrightside(*inbufptr)){
+	    /* select GR side */
+	    ctdp = GR_ctdp;
+	    length = ctdp->length;
+	    ct_type = ctdp->ct_type;
+	}
 	if (*inbufptr == '\033' || *inbufptr == (char)'\233') {
 	    for (ctdp = ctdata; ctdp <= ctd_endp ; ctdp++) {
 
@@ -1288,6 +1328,11 @@
 			}
 		    }
 		    ct_type = ctdp->ct_type;
+		    if(ctdp->side == XlcGL){
+			GL_ctdp = ctdp; /* save GL ctdp */
+		    }else{
+			GR_ctdp = ctdp; /* save GR ctdp */
+		    }
 		    break;
 		}
 	    }

Re: Copy/Paste problems when contains non-ascii characters

[Jay Smith]

Hi Harold,

Thanks for your input.  Either I don't understand all of what you are 
saying or you don't understand the problem -- though Windows 95 is always a 
problem. :-)

I *can* copy/paste from Linux Mozilla 1.4 to Windows 95.  That is okay.

What I *can't* do is copy/paste within Linux Mozilla 1.4 (running in X, 
when the copy contains European characters....)

When I was using Linux Mozilla 1.2, the paste truncated immediately before 
the European character.  Now, under Linux Mozilla 1.4, the paste is null 
(nothing pastes).

I was doing this all the time under Linux Mozilla 1.2 (since about February 
2003) without any problem (other than the darn truncation).  No crashes or 
other problems of that nature.

Regarding getting off Windows 95 you are quite right, however, the 
economics are not as you assume.  What it really means is a) also replacing 
all the workstations (these are Pentium 200 or 300 machines); b) switching 
to Linux *IF* Linux could get its productivity apps up to a productive 
level (I don't mind twiddling around with them, but I certainly can't have 
my staff -- who are lucky to find the "on" button) dealing the the Linux 
problems I have to deal with every day; c) finding, replacing, configuring, 
and learning software for the roughly 30 (thirty) apps we run.  Even if we 
stayed with Windows (going to 2000 Professional probably), just replacing 
the apps would cost $3000+ per seat and the machines around $1500 per seat. 
In a small company like mine, a conversion like this could put us out of 
business if we are not careful.  A week out of business is close to our 
annual profit.  Thus we hang on until we really have to make the switch. 
Hopefully Linux will get there (but the bugs I have encountered in only 2 
days of use of Mozilla 1.4 make me wonder.....)

Jay

Harold L Hunt II said the following on 10/12/2003 07:24 PM:
> Jay,
> 
> Your problem is that you are using Windows 95, which does not natively 
> support unicode text.  There is support in Cygwin/XFree86 for converting 
> characters to unicode and back, but it only works on NT-based platforms 
> (NT 4.0, Windows 2000, Windows XP, Windows Server 2003).
> 
> The Microsoft Layer for Unicode on Windows 95/98/Me Systems should allow 
> the support to work properly, but we would have to change the unicode 
> support detection slightly for this to take effect.  Have you installed 
> the unicode support for Windows 95?  More information and a link to 
> download are here:
> 
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/devnotes/winprog/microsoft_layer_for_unicode_on_windows_95_98_me_systems.asp 
> 
> 
> Or, the tiny url to the same thing:
> 
> http://tinyurl.com/qo9n
> 
> 
> Hmm... just did some more checking... using the Layer for Unicode 
> support will not be trivial.  Kensuke may be interested in it as an 
> alternative to using libiconv on Windows 95/98/Me.
> 
> As for why you text copying is truncated vs. not appearing at all, I 
> suspect that Mozilla 1.2.x to 1.4 changed the format of some clipboard 
> data from plain text to INCR.  But that would only make sense if you 
> have only tried this with the versions of XFree86-xserv that don't crash 
> when they see an INCR clipboard format.  If you didn't try this until 
> recently, then that would explain your problem.  You should at least be 
> thankful that XWin.exe doesn't core dump like it used to in these cases.
> 
> In summary, your problem is known, it isn't trivial to solve, and the 
> change from Mozilla 1.2.x to 1.4 is due to a change that they made, not 
> something that we did.  Also, your issue is already known to be not an 
> issue on NT-based platforms, so the Microsoft answer to this problem 
> would be "The Cygwin/XFree86 has identified this to be a problem with 
> the products listed above.", with the idea being that they might fix it 
> or they might not, but perhaps you should consider upgrading to a more 
> recent version of Windows.  In other words, you are more likely to get 
> your problem fixed by spending $200 of your own money upgrading to 
> Windows XP, versus me spending $2000 of my time to cobble together a fix 
> for Windows 95/98/Me.  That's just being honest.
> 
> Thanks for testing,
> 
> Harold
> 
> Jay Smith wrote:
> 
>> Hi,
>>
>> My copy/paste behavior in MOZILLA running on RedHat 8 LINUX has gone 
>> from bad to worse when I upgraded the Mozilla from 1.2.x to 1.4.
>>
>> Important: The Mozilla is LINUX Mozilla running on an RH8 server.  I 
>> am sitting at a Windows 95 PC, using Cygwin/XFree86 to run an X 
>> session on the PC.  I am sitting at a PC, not at a Linux box.  (Most 
>> people don't get this and thus reply using wrong assumptions.)
>>
>> WHEN RUNNING Linux Mozilla ON PC USING CYGWIN:
>>
>> (old) MOZ 1.2.x: When I copied text that contained a non-ascii typical 
>> European or Scandinavian character from an existing email and PASTED 
>> INTO A MOZILLA MAIL COMPOSE window, the text up to, but NOT including, 
>> the character would copy AND PASTE. That was bad, but at least you got 
>> something (the text before the character).
>>
>> (new) MOZ 1.4: However, now, if the copy contains such a character, 
>> NOTHING gets pasted into A MOZILLA MAIL COMPOSE window.  It changed 
>> from partial to nothing.
>>
>> I AM still able to paste full and properly into windows applications 
>> from Mozilla, including such common European and Scandinvian characters.
>>
>> Because there has been no change to the Cygwin installation on this PC, I
>> don't think the *change* in the problem is related to that.  However, 
>> the root of the problem seems to be related to Cygwin.
>>
>> By contrast, IF I AM WORKING DIRECTLY/PHYSICALLY ON THE LINUX SERVER:
>>
>> Mozilla 1.2.x or 1.4: I *CAN* fully and properly cut/paste the very 
>> same text.
>>
>> MY ENVIRONMENT IS:
>>
>> Server: Red Hat Linux 8
>>
>> Workstation: Windows 95 running Cygwin ....
>> (I think these are the version numbers of what I have installed; they 
>> were as of April 2003 and I don't think I have installed any new 
>> Cygwin stuff on this machine since then -- but I don't know how to 
>> find out what versions I am running. How do I?)
>>   XFree86-base     4.2.0-1
>>          -lib      4.2.0-5
>>          -xserv    4.2.0-28
>>          -xwinclip 4.2.0-8
>>
>> Jay

-- 
Jay Smith

e-mail: Jay@JaySmith.com  mailto:Jay@JaySmith.com
website: http://www.JaySmith.com

Jay Smith & Associates
P.O. Box 650
Snow Camp, NC  27349  USA

Phone: Int+US+336-376-9991
Toll-Free Phone in US & Canada:
	1-800-447-8267
Fax: Int+US+336-376-6750

Re: [PATCH] Copy/Paste non-ascii characters

[Jay Smith]

Dear Kensuke,

Thank you very much for your effort on this.

Unfortunately, I am pretty ignorant of these matters, thus you will have to 
tell me what it is that I should do with the two .diff files you attached. 
I will be happy to do whatever with them, but I am clueless as to what is 
to be done with them.

Sorry to be a pain.

Jay

Kensuke Matsuzaki said the following on 10/12/2003 09:33 PM:
> Jay,
> 
> Perhaps this patch enable XWin to copy/paste non-ascii characters
> even if Windows does't support Unicode (95/98/Me).
> LANG environment variable and Windows locale must be same.
> I added -nounicodeclipboard option, I tested using this on XP.
> But I don't have 95/98/Me.
> 
> And it seems tha libX11 has some CTEXT convertion bug, I attach
> patch that based on TAKABE's work.
> http://www.ff.iij4u.or.jp/~t-takabe/xf410_xim_fix.diff
> 
> By the way, nls/locale.alias has alias somethig like
> "Arabic_Egypt.1256". Can we use that?
> If so, we no longer need LANG environment variable.
> We can get it following code.
> 
>   char pszCountry[128];
>   char pszLanguage[128];
>   int nAcp = GetACP ();
>   
>   GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGCOUNTRY, pszCountry, 128);
>   GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGLANGUAGE, pszLanguage, 128);
> 
>   printf ("%s_%s.%d\n", pszLanguage, pszCountry, nAcp);
> 
> Kensuke Matsuzaki

-- 
Jay Smith

e-mail: Jay@JaySmith.com  mailto:Jay@JaySmith.com
website: http://www.JaySmith.com

Jay Smith & Associates
P.O. Box 650
Snow Camp, NC  27349  USA

Phone: Int+US+336-376-9991
Toll-Free Phone in US & Canada:
	1-800-447-8267
Fax: Int+US+336-376-6750

Re: [PATCH] Copy/Paste non-ascii characters

[Harold L Hunt II]

Jay,

I think he probably sent the patches for me to make a release with.  You 
shouldn't have to do anything with them yourself.

Harold

Jay Smith wrote:
> Dear Kensuke,
> 
> Thank you very much for your effort on this.
> 
> Unfortunately, I am pretty ignorant of these matters, thus you will have 
> to tell me what it is that I should do with the two .diff files you 
> attached. I will be happy to do whatever with them, but I am clueless as 
> to what is to be done with them.
> 
> Sorry to be a pain.
> 
> Jay
> 
> Kensuke Matsuzaki said the following on 10/12/2003 09:33 PM:
> 
>> Jay,
>>
>> Perhaps this patch enable XWin to copy/paste non-ascii characters
>> even if Windows does't support Unicode (95/98/Me).
>> LANG environment variable and Windows locale must be same.
>> I added -nounicodeclipboard option, I tested using this on XP.
>> But I don't have 95/98/Me.
>>
>> And it seems tha libX11 has some CTEXT convertion bug, I attach
>> patch that based on TAKABE's work.
>> http://www.ff.iij4u.or.jp/~t-takabe/xf410_xim_fix.diff
>>
>> By the way, nls/locale.alias has alias somethig like
>> "Arabic_Egypt.1256". Can we use that?
>> If so, we no longer need LANG environment variable.
>> We can get it following code.
>>
>>   char pszCountry[128];
>>   char pszLanguage[128];
>>   int nAcp = GetACP ();
>>     GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGCOUNTRY, 
>> pszCountry, 128);
>>   GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGLANGUAGE, 
>> pszLanguage, 128);
>>
>>   printf ("%s_%s.%d\n", pszLanguage, pszCountry, nAcp);
>>
>> Kensuke Matsuzaki
> 
> 

Re: [PATCH] Copy/Paste non-ascii characters

[Harold L Hunt II]

Kensuke,

Do you think the following change that you made might stop a potential 
memory leak?

        /* */
        if (nNum && ppList && *ppList)
  	{
-	  XFree (xtpName.value);
  	  *ppName = strdup (*ppList);
  	  XFreeStringList (ppList);
  	}
+      XFree (xtpName.value);

Harold

Kensuke Matsuzaki wrote:

> Jay,
> 
> Perhaps this patch enable XWin to copy/paste non-ascii characters
> even if Windows does't support Unicode (95/98/Me).
> LANG environment variable and Windows locale must be same.
> I added -nounicodeclipboard option, I tested using this on XP.
> But I don't have 95/98/Me.
> 
> And it seems tha libX11 has some CTEXT convertion bug, I attach
> patch that based on TAKABE's work.
> http://www.ff.iij4u.or.jp/~t-takabe/xf410_xim_fix.diff
> 
> By the way, nls/locale.alias has alias somethig like
> "Arabic_Egypt.1256". Can we use that?
> If so, we no longer need LANG environment variable.
> We can get it following code.
> 
>   char pszCountry[128];
>   char pszLanguage[128];
>   int nAcp = GetACP ();
>   
>   GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGCOUNTRY, pszCountry, 128);
>   GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGLANGUAGE, pszLanguage, 128);
> 
>   printf ("%s_%s.%d\n", pszLanguage, pszCountry, nAcp);
> 
> Kensuke Matsuzaki

Using nls/locale.alias [ago please comment]

[Harold L Hunt II]

Kensuke Matsuzaki wrote:
> By the way, nls/locale.alias has alias somethig like
> "Arabic_Egypt.1256". Can we use that?
> If so, we no longer need LANG environment variable.

I didn't know that we currently needed the LANG environment variable.  I 
don't really know enough about this stuff to contribute a useful 
suggestion here.  I think I will do whatever you and Alexander think 
will work.  Of course, I am always willing to try something out and 
change it back if it fails for too many people.

Harold

> We can get it following code.
> 
>   char pszCountry[128];
>   char pszLanguage[128];
>   int nAcp = GetACP ();
>   
>   GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGCOUNTRY, pszCountry, 128);
>   GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGLANGUAGE, pszLanguage, 128);
> 
>   printf ("%s_%s.%d\n", pszLanguage, pszCountry, nAcp);
> 
> Kensuke Matsuzaki

Re: [PATCH] Copy/Paste non-ascii characters

[Harold L Hunt II]

Jay,

I just posted XFree86-xserv-4.3.0-20 as a 'test' package; it should be 
showing up on mirrors within a few hours.  When it does, run setup.exe 
and manually select version '4.3.0-20' for the XFree86-xserv package. 
Then, run the new server version as usual (do not use the new flag that 
Kensuke talked about) and report your results to the mailing list.

Harold

Jay Smith wrote:

> Dear Kensuke,
> 
> Thank you very much for your effort on this.
> 
> Unfortunately, I am pretty ignorant of these matters, thus you will have 
> to tell me what it is that I should do with the two .diff files you 
> attached. I will be happy to do whatever with them, but I am clueless as 
> to what is to be done with them.
> 
> Sorry to be a pain.
> 
> Jay
> 
> Kensuke Matsuzaki said the following on 10/12/2003 09:33 PM:
> 
>> Jay,
>>
>> Perhaps this patch enable XWin to copy/paste non-ascii characters
>> even if Windows does't support Unicode (95/98/Me).
>> LANG environment variable and Windows locale must be same.
>> I added -nounicodeclipboard option, I tested using this on XP.
>> But I don't have 95/98/Me.
>>
>> And it seems tha libX11 has some CTEXT convertion bug, I attach
>> patch that based on TAKABE's work.
>> http://www.ff.iij4u.or.jp/~t-takabe/xf410_xim_fix.diff
>>
>> By the way, nls/locale.alias has alias somethig like
>> "Arabic_Egypt.1256". Can we use that?
>> If so, we no longer need LANG environment variable.
>> We can get it following code.
>>
>>   char pszCountry[128];
>>   char pszLanguage[128];
>>   int nAcp = GetACP ();
>>     GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGCOUNTRY, 
>> pszCountry, 128);
>>   GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGLANGUAGE, 
>> pszLanguage, 128);
>>
>>   printf ("%s_%s.%d\n", pszLanguage, pszCountry, nAcp);
>>
>> Kensuke Matsuzaki
> 
> 

CTEXT conversion patch

[Harold L Hunt II]

Kensuke,



Kensuke Matsuzaki wrote:
> And it seems tha libX11 has some CTEXT convertion bug, I attach
> patch that based on TAKABE's work.
> http://www.ff.iij4u.or.jp/~t-takabe/xf410_xim_fix.diff

Could you send me more information on this?  Please describe what the 
current problem is.  Please send any links to a message or post that 
describes what the patch does.  Do you have Takabe's email address as well?

If you can send me those things then I can make sure that this patch 
makes it into XFree86, as long as it is a valid patch.  Right now, I 
don't know how to describe what it does.  :)

Harold

Re: Using nls/locale.alias [ago please comment]

[Kensuke Matsuzaki]

Harold,

> > By the way, nls/locale.alias has alias somethig like
> > "Arabic_Egypt.1256". Can we use that?
> > If so, we no longer need LANG environment variable.
> 
> I didn't know that we currently needed the LANG environment variable.  I 
> don't really know enough about this stuff to contribute a useful 
> suggestion here.  I think I will do whatever you and Alexander think 
> will work.  Of course, I am always willing to try something out and 
> change it back if it fails for too many people.

We must know CF_TEXT text encoding to convert it to CTEXT/UTF-8.

XmbTextListToTextProperty requires input text to be encoded by
current locale encoding. XmbTextPropertyToTextList's output text is
encoded using current locale encoding.
setlocale set those data, and it look at LC_CTYPE or LANG if second
parameter of setlocale is "".

Xutf8* use UTF-8 encoding so they work without LANG/LC_CTYPE.

Kensuke Matsuzaki

Re: CTEXT conversion patch

[Kensuke Matsuzaki]

Harold,

It was posted in discussion board.
http://matsu-www.is.titech.ac.jp/~sohda/cygwin/treebbs/treebbs.cgi?kako=1&all=10&s=10
He said that 
"This fix following two problem.
1. X freeze when we have 2 byte string after 1 byte string using
  ASTEX-X's XIM.
2. We can't use XIM on Cygwin/XFree86 4.1.0 etc."

Second problem is fixed
http://cvsweb.xfree86.org/cvsweb/xc/lib/X11/lcSjis.c.diff?r1=3.9&r2=3.10
and
http://cvsweb.xfree86.org/cvsweb/xc/lib/X11/lcEuc.c.diff?r1=3.11&r2=3.12
that Allow UTF8 conversion to work for Japanese locales (#A.1527, Etsushi Kato).

So I delete code that related 2nd problem.

I write about 1st problem.
CTEXT has GL and GR two graphic character sets.
But CTEXT to multi-byte string/wide string converter in lcSjis.c
and lcEuc.c have only signle set. So text use GR convertion fail.
Those fix patch was wrote by TAKABE.

I added following code.
if (charset == ct_state.GR_charset) {
    clen = charset->length;
    do {
	(*(Uchar *)(ctptr-clen)) = BIT8ON(*(Uchar *)(ctptr-clen));
    } while (--clen); 
}
Because multi-byte text to CTEXT converter in lcSjis.c doesn't
set 8-bit on even if it is in GR.

I don't know his mail address.

At Sun, 12 Oct 2003 23:05:57 -0400,
Harold L Hunt II wrote:
> 
> Kensuke,
> 
> 
> 
> Kensuke Matsuzaki wrote:
> > And it seems tha libX11 has some CTEXT convertion bug, I attach
> > patch that based on TAKABE's work.
> > http://www.ff.iij4u.or.jp/~t-takabe/xf410_xim_fix.diff
> 
> Could you send me more information on this?  Please describe what the 
> current problem is.  Please send any links to a message or post that 
> describes what the patch does.  Do you have Takabe's email address as well?
> 
> If you can send me those things then I can make sure that this patch 
> makes it into XFree86, as long as it is a valid patch.  Right now, I 
> don't know how to describe what it does.  :)
> 
> Harold

Kensuke Matsuzaki

Re: [PATCH] Copy/Paste non-ascii characters

[Jay Smith]

Harold,

a) Before I attempt this fix, will this work with my old version of 
everything else?  I know that Cygwin has moved ahead since April.  Or does 
installing this start me down a slippery slope...

b) Before I had the sense to ask the question above, I got as far as 
starting the download process from a mirror that I had previously used. The 
  setup program warned me that a newer setup.ini file would replace the old 
one, but did not seem to give me a way to cancel out.  So, now I have an 
new setup.ini but old "everything else" files -- and I *do* need the "old 
everything else" to reinstall on PCs that die, etc.  Am I screwed?

Jay


Harold L Hunt II said the following on 10/12/2003 11:01 PM:
> Jay,
> 
> I just posted XFree86-xserv-4.3.0-20 as a 'test' package; it should be 
> showing up on mirrors within a few hours.  When it does, run setup.exe 
> and manually select version '4.3.0-20' for the XFree86-xserv package. 
> Then, run the new server version as usual (do not use the new flag that 
> Kensuke talked about) and report your results to the mailing list.
> 
> Harold
> 
> Jay Smith wrote:
> 
>> Dear Kensuke,
>>
>> Thank you very much for your effort on this.
>>
>> Unfortunately, I am pretty ignorant of these matters, thus you will 
>> have to tell me what it is that I should do with the two .diff files 
>> you attached. I will be happy to do whatever with them, but I am 
>> clueless as to what is to be done with them.
>>
>> Sorry to be a pain.
>>
>> Jay
>>
>> Kensuke Matsuzaki said the following on 10/12/2003 09:33 PM:
>>
>>> Jay,
>>>
>>> Perhaps this patch enable XWin to copy/paste non-ascii characters
>>> even if Windows does't support Unicode (95/98/Me).
>>> LANG environment variable and Windows locale must be same.
>>> I added -nounicodeclipboard option, I tested using this on XP.
>>> But I don't have 95/98/Me.
>>>
>>> And it seems tha libX11 has some CTEXT convertion bug, I attach
>>> patch that based on TAKABE's work.
>>> http://www.ff.iij4u.or.jp/~t-takabe/xf410_xim_fix.diff
>>>
>>> By the way, nls/locale.alias has alias somethig like
>>> "Arabic_Egypt.1256". Can we use that?
>>> If so, we no longer need LANG environment variable.
>>> We can get it following code.
>>>
>>>   char pszCountry[128];
>>>   char pszLanguage[128];
>>>   int nAcp = GetACP ();
>>>     GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGCOUNTRY, 
>>> pszCountry, 128);
>>>   GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGLANGUAGE, 
>>> pszLanguage, 128);
>>>
>>>   printf ("%s_%s.%d\n", pszLanguage, pszCountry, nAcp);
>>>
>>> Kensuke Matsuzaki
>>
>>
>>

-- 
Jay Smith

e-mail: Jay@JaySmith.com  mailto:Jay@JaySmith.com
website: http://www.JaySmith.com

Jay Smith & Associates
P.O. Box 650
Snow Camp, NC  27349  USA

Phone: Int+US+336-376-9991
Toll-Free Phone in US & Canada:
	1-800-447-8267
Fax: Int+US+336-376-6750

Re: [PATCH] Copy/Paste non-ascii characters

[Harold L Hunt II]

Jay,

Jay Smith wrote:
> Harold,
> 
> a) Before I attempt this fix, will this work with my old version of 
> everything else?  I know that Cygwin has moved ahead since April.  Or 
> does installing this start me down a slippery slope...

I hate when I forget to ask this if people are running the latest 
version or not.  You really need to be running the latest versions in 
order for us to properly debug and test things.

Yes, you will have to update to the 4.3.0 release of Cygwin/XFree86.  I 
think I released it after April.  All of the DLLs have had their names 
changed, so you need to get those (in the -bin package) but I believe I 
made the fonts in such a way that they will not download again unless 
you have a really old version.  You will basically need to get anything 
that has a new version, since there have been updates to Cygwin's DLL, 
various libraries, etc.

> b) Before I had the sense to ask the question above, I got as far as 
> starting the download process from a mirror that I had previously used. 
> The  setup program warned me that a newer setup.ini file would replace 
> the old one, but did not seem to give me a way to cancel out.  So, now I 
> have an new setup.ini but old "everything else" files -- and I *do* need 
> the "old everything else" to reinstall on PCs that die, etc.  Am I screwed?

Setup gives a warning about setup.ini telling it that there is a new 
version of setup.exe available and that you don't have it.  Download the 
latest setup.exe and you won't get the warning (plus there has been a 
lot of development on setup.exe in the last several months).

I'm not sure about the status of your installation images.  It sounds 
like you have been doing a download to disk then installing from that? 
Uh... guess all I can tell you is that you should have backed up first 
:)  Of course, you could just look at files that have been updated 
recently and check if setup.exe made a backup of the old setup.ini that 
you had.

Harold


> Jay
> 
> 
> Harold L Hunt II said the following on 10/12/2003 11:01 PM:
> 
>> Jay,
>>
>> I just posted XFree86-xserv-4.3.0-20 as a 'test' package; it should be 
>> showing up on mirrors within a few hours.  When it does, run setup.exe 
>> and manually select version '4.3.0-20' for the XFree86-xserv package. 
>> Then, run the new server version as usual (do not use the new flag 
>> that Kensuke talked about) and report your results to the mailing list.
>>
>> Harold
>>
>> Jay Smith wrote:
>>
>>> Dear Kensuke,
>>>
>>> Thank you very much for your effort on this.
>>>
>>> Unfortunately, I am pretty ignorant of these matters, thus you will 
>>> have to tell me what it is that I should do with the two .diff files 
>>> you attached. I will be happy to do whatever with them, but I am 
>>> clueless as to what is to be done with them.
>>>
>>> Sorry to be a pain.
>>>
>>> Jay
>>>
>>> Kensuke Matsuzaki said the following on 10/12/2003 09:33 PM:
>>>
>>>> Jay,
>>>>
>>>> Perhaps this patch enable XWin to copy/paste non-ascii characters
>>>> even if Windows does't support Unicode (95/98/Me).
>>>> LANG environment variable and Windows locale must be same.
>>>> I added -nounicodeclipboard option, I tested using this on XP.
>>>> But I don't have 95/98/Me.
>>>>
>>>> And it seems tha libX11 has some CTEXT convertion bug, I attach
>>>> patch that based on TAKABE's work.
>>>> http://www.ff.iij4u.or.jp/~t-takabe/xf410_xim_fix.diff
>>>>
>>>> By the way, nls/locale.alias has alias somethig like
>>>> "Arabic_Egypt.1256". Can we use that?
>>>> If so, we no longer need LANG environment variable.
>>>> We can get it following code.
>>>>
>>>>   char pszCountry[128];
>>>>   char pszLanguage[128];
>>>>   int nAcp = GetACP ();
>>>>     GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGCOUNTRY, 
>>>> pszCountry, 128);
>>>>   GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGLANGUAGE, 
>>>> pszLanguage, 128);
>>>>
>>>>   printf ("%s_%s.%d\n", pszLanguage, pszCountry, nAcp);
>>>>
>>>> Kensuke Matsuzaki
>>>
>>>
>>>
>>>
> 

Re: [PATCH] Copy/Paste non-ascii characters

[Jay Smith]

Harold,

Before I embark on upgrading all of Cygwin to deal with this, is there any 
risk that stuff will break?  Since Cygwin underwent a major overhaul 
recently, it seems to me that there is a chance that some small parts of 
XFree86 stuff (I use little else) might be broken until all is brought up 
to speed.

Since this is a minute-to-minute critical application (X windowing) upon 
which we rely 100%, I have to be very careful about changes.  (Recalling 
recent RedHat library changes which broke lots of stuff and recent Perl 
version changes which wrecked our CGI scripts.)

What is the status? Does all the XFree86 stuff work under the new Cygwin? 
Is it "safe" now?  (I know that in the first few weeks it was not "safe".)

Jay

Harold L Hunt II said the following on 10/14/2003 09:23 PM:
> Jay,
> 
> Jay Smith wrote:
> 
>> Harold,
>>
>> a) Before I attempt this fix, will this work with my old version of 
>> everything else?  I know that Cygwin has moved ahead since April.  Or 
>> does installing this start me down a slippery slope...
> 
> 
> I hate when I forget to ask this if people are running the latest 
> version or not.  You really need to be running the latest versions in 
> order for us to properly debug and test things.
> 
> Yes, you will have to update to the 4.3.0 release of Cygwin/XFree86.  I 
> think I released it after April.  All of the DLLs have had their names 
> changed, so you need to get those (in the -bin package) but I believe I 
> made the fonts in such a way that they will not download again unless 
> you have a really old version.  You will basically need to get anything 
> that has a new version, since there have been updates to Cygwin's DLL, 
> various libraries, etc.
> 
>> b) Before I had the sense to ask the question above, I got as far as 
>> starting the download process from a mirror that I had previously 
>> used. The  setup program warned me that a newer setup.ini file would 
>> replace the old one, but did not seem to give me a way to cancel out.  
>> So, now I have an new setup.ini but old "everything else" files -- and 
>> I *do* need the "old everything else" to reinstall on PCs that die, 
>> etc.  Am I screwed?
> 
> 
> Setup gives a warning about setup.ini telling it that there is a new 
> version of setup.exe available and that you don't have it.  Download the 
> latest setup.exe and you won't get the warning (plus there has been a 
> lot of development on setup.exe in the last several months).
> 
> I'm not sure about the status of your installation images.  It sounds 
> like you have been doing a download to disk then installing from that? 
> Uh... guess all I can tell you is that you should have backed up first 
> :)  Of course, you could just look at files that have been updated 
> recently and check if setup.exe made a backup of the old setup.ini that 
> you had.
> 
> Harold
> 
> 
>> Jay
>>
>>
>> Harold L Hunt II said the following on 10/12/2003 11:01 PM:
>>
>>> Jay,
>>>
>>> I just posted XFree86-xserv-4.3.0-20 as a 'test' package; it should 
>>> be showing up on mirrors within a few hours.  When it does, run 
>>> setup.exe and manually select version '4.3.0-20' for the 
>>> XFree86-xserv package. Then, run the new server version as usual (do 
>>> not use the new flag that Kensuke talked about) and report your 
>>> results to the mailing list.
>>>
>>> Harold
>>>
>>> Jay Smith wrote:
>>>
>>>> Dear Kensuke,
>>>>
>>>> Thank you very much for your effort on this.
>>>>
>>>> Unfortunately, I am pretty ignorant of these matters, thus you will 
>>>> have to tell me what it is that I should do with the two .diff files 
>>>> you attached. I will be happy to do whatever with them, but I am 
>>>> clueless as to what is to be done with them.
>>>>
>>>> Sorry to be a pain.
>>>>
>>>> Jay
>>>>
>>>> Kensuke Matsuzaki said the following on 10/12/2003 09:33 PM:
>>>>
>>>>> Jay,
>>>>>
>>>>> Perhaps this patch enable XWin to copy/paste non-ascii characters
>>>>> even if Windows does't support Unicode (95/98/Me).
>>>>> LANG environment variable and Windows locale must be same.
>>>>> I added -nounicodeclipboard option, I tested using this on XP.
>>>>> But I don't have 95/98/Me.
>>>>>
>>>>> And it seems tha libX11 has some CTEXT convertion bug, I attach
>>>>> patch that based on TAKABE's work.
>>>>> http://www.ff.iij4u.or.jp/~t-takabe/xf410_xim_fix.diff
>>>>>
>>>>> By the way, nls/locale.alias has alias somethig like
>>>>> "Arabic_Egypt.1256". Can we use that?
>>>>> If so, we no longer need LANG environment variable.
>>>>> We can get it following code.
>>>>>
>>>>>   char pszCountry[128];
>>>>>   char pszLanguage[128];
>>>>>   int nAcp = GetACP ();
>>>>>     GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGCOUNTRY, 
>>>>> pszCountry, 128);
>>>>>   GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGLANGUAGE, 
>>>>> pszLanguage, 128);
>>>>>
>>>>>   printf ("%s_%s.%d\n", pszLanguage, pszCountry, nAcp);
>>>>>
>>>>> Kensuke Matsuzaki
>>>>
>>>>
>>>>
>>>>
>>>>
>>

-- 
Jay Smith

e-mail: Jay@JaySmith.com  mailto:Jay@JaySmith.com
website: http://www.JaySmith.com

Jay Smith & Associates
P.O. Box 650
Snow Camp, NC  27349  USA

Phone: Int+US+336-376-9991
Toll-Free Phone in US & Canada:
	1-800-447-8267
Fax: Int+US+336-376-6750

Re: [PATCH] Copy/Paste non-ascii characters

[Harold L Hunt II]

Jay,

The status is that XFree86 has been recompiled and rereleased for Cygwin 
1.5.x.  Everything should be "safe".  However, I would always recommend 
doing a demo installation on one machine and trying out your apps before 
you upgrade all machines.  That should give you a better idea of if it 
will work for you.

One thing you can do is rename c:\cygwin to c:\cygwin_works, download 
setup.exe to c:\cyginstall_test, then run setup.exe and install to 
c:\cygwin (which is now an empty directory).  This will allow you to 
test a complete new install and see if it works for you.  You can then 
move c:\cygwin to c:\cygwin_test and move c:\cygwin_works back to 
c:\cygwin to restore your old installation.

Harold

Jay Smith wrote:
> Harold,
> 
> Before I embark on upgrading all of Cygwin to deal with this, is there 
> any risk that stuff will break?  Since Cygwin underwent a major overhaul 
> recently, it seems to me that there is a chance that some small parts of 
> XFree86 stuff (I use little else) might be broken until all is brought 
> up to speed.
> 
> Since this is a minute-to-minute critical application (X windowing) upon 
> which we rely 100%, I have to be very careful about changes.  (Recalling 
> recent RedHat library changes which broke lots of stuff and recent Perl 
> version changes which wrecked our CGI scripts.)
> 
> What is the status? Does all the XFree86 stuff work under the new 
> Cygwin? Is it "safe" now?  (I know that in the first few weeks it was 
> not "safe".)
> 
> Jay
> 
> Harold L Hunt II said the following on 10/14/2003 09:23 PM:
> 
>> Jay,
>>
>> Jay Smith wrote:
>>
>>> Harold,
>>>
>>> a) Before I attempt this fix, will this work with my old version of 
>>> everything else?  I know that Cygwin has moved ahead since April.  Or 
>>> does installing this start me down a slippery slope...
>>
>>
>>
>> I hate when I forget to ask this if people are running the latest 
>> version or not.  You really need to be running the latest versions in 
>> order for us to properly debug and test things.
>>
>> Yes, you will have to update to the 4.3.0 release of Cygwin/XFree86.  
>> I think I released it after April.  All of the DLLs have had their 
>> names changed, so you need to get those (in the -bin package) but I 
>> believe I made the fonts in such a way that they will not download 
>> again unless you have a really old version.  You will basically need 
>> to get anything that has a new version, since there have been updates 
>> to Cygwin's DLL, various libraries, etc.
>>
>>> b) Before I had the sense to ask the question above, I got as far as 
>>> starting the download process from a mirror that I had previously 
>>> used. The  setup program warned me that a newer setup.ini file would 
>>> replace the old one, but did not seem to give me a way to cancel 
>>> out.  So, now I have an new setup.ini but old "everything else" files 
>>> -- and I *do* need the "old everything else" to reinstall on PCs that 
>>> die, etc.  Am I screwed?
>>
>>
>>
>> Setup gives a warning about setup.ini telling it that there is a new 
>> version of setup.exe available and that you don't have it.  Download 
>> the latest setup.exe and you won't get the warning (plus there has 
>> been a lot of development on setup.exe in the last several months).
>>
>> I'm not sure about the status of your installation images.  It sounds 
>> like you have been doing a download to disk then installing from that? 
>> Uh... guess all I can tell you is that you should have backed up first 
>> :)  Of course, you could just look at files that have been updated 
>> recently and check if setup.exe made a backup of the old setup.ini 
>> that you had.
>>
>> Harold
>>
>>
>>> Jay
>>>
>>>
>>> Harold L Hunt II said the following on 10/12/2003 11:01 PM:
>>>
>>>> Jay,
>>>>
>>>> I just posted XFree86-xserv-4.3.0-20 as a 'test' package; it should 
>>>> be showing up on mirrors within a few hours.  When it does, run 
>>>> setup.exe and manually select version '4.3.0-20' for the 
>>>> XFree86-xserv package. Then, run the new server version as usual (do 
>>>> not use the new flag that Kensuke talked about) and report your 
>>>> results to the mailing list.
>>>>
>>>> Harold
>>>>
>>>> Jay Smith wrote:
>>>>
>>>>> Dear Kensuke,
>>>>>
>>>>> Thank you very much for your effort on this.
>>>>>
>>>>> Unfortunately, I am pretty ignorant of these matters, thus you will 
>>>>> have to tell me what it is that I should do with the two .diff 
>>>>> files you attached. I will be happy to do whatever with them, but I 
>>>>> am clueless as to what is to be done with them.
>>>>>
>>>>> Sorry to be a pain.
>>>>>
>>>>> Jay
>>>>>
>>>>> Kensuke Matsuzaki said the following on 10/12/2003 09:33 PM:
>>>>>
>>>>>> Jay,
>>>>>>
>>>>>> Perhaps this patch enable XWin to copy/paste non-ascii characters
>>>>>> even if Windows does't support Unicode (95/98/Me).
>>>>>> LANG environment variable and Windows locale must be same.
>>>>>> I added -nounicodeclipboard option, I tested using this on XP.
>>>>>> But I don't have 95/98/Me.
>>>>>>
>>>>>> And it seems tha libX11 has some CTEXT convertion bug, I attach
>>>>>> patch that based on TAKABE's work.
>>>>>> http://www.ff.iij4u.or.jp/~t-takabe/xf410_xim_fix.diff
>>>>>>
>>>>>> By the way, nls/locale.alias has alias somethig like
>>>>>> "Arabic_Egypt.1256". Can we use that?
>>>>>> If so, we no longer need LANG environment variable.
>>>>>> We can get it following code.
>>>>>>
>>>>>>   char pszCountry[128];
>>>>>>   char pszLanguage[128];
>>>>>>   int nAcp = GetACP ();
>>>>>>     GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGCOUNTRY, 
>>>>>> pszCountry, 128);
>>>>>>   GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGLANGUAGE, 
>>>>>> pszLanguage, 128);
>>>>>>
>>>>>>   printf ("%s_%s.%d\n", pszLanguage, pszCountry, nAcp);
>>>>>>
>>>>>> Kensuke Matsuzaki
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
> 

results/problems (Re: [PATCH] Copy/Paste non-ascii characters)

[Jay Smith]

Harold,

I have done the installation and I have several things to report. If some 
of these are not for this list, please advise.  First of all, FYI, when I 
did the install, Progeny would not respond at all so I used Purdue.  In any 
case, I turned OFF everything and then turned on only XFree xserve, 
scalable fonts, and xwinclip -- those of course caused some other things to 
turn on automatically.

1) The main problem of copy/paste of non-ascii characters *within* Linux 
Mozilla seems to be *fixed*.  Thanks!

However....

2) I had my own modified script (with its own unique filename) that was 
used to start X; I guess this was before startxdmcp.bat was available.  I 
copied my script into place. However, when I run MY script now, it seems 
like the command (in MY script)
    start XWin -nodecoration -clipboard -once -query jsa.jaysmith.com
actually (also?) RUNS startxdmcp.bat

    That is very odd and I am not sure what to do.  I had to modify 
startxdmcp.bat to bring it in line with my script so the proper command 
would get done.

    I believe that startxdmcp.bat is getting run because the DOS box that 
appears says so, identifying it by name -- even if *I* don't directly run it.

3) I think that startxdmcp.bat may have an error in it.  The original 
version of it has the command:

       start XWin -query %REMOTE_HOST% -nodecoration -lesspointer

    and this causes an error in the DOS box about "too many paramaters". I 
am certainly no expert, but I think that the "-query ...." should be the 
LAST thing on the command line.  Anyway, when I made it so (like my 
original script) it worked without putting out the error.

4) Generally X performance seems to be better.  It is very subjective, but 
so good, so far.

Jay

Harold L Hunt II said the following on 10/14/2003 10:28 PM:
> Jay,
> 
> The status is that XFree86 has been recompiled and rereleased for Cygwin 
> 1.5.x.  Everything should be "safe".  However, I would always recommend 
> doing a demo installation on one machine and trying out your apps before 
> you upgrade all machines.  That should give you a better idea of if it 
> will work for you.
> 
> One thing you can do is rename c:\cygwin to c:\cygwin_works, download 
> setup.exe to c:\cyginstall_test, then run setup.exe and install to 
> c:\cygwin (which is now an empty directory).  This will allow you to 
> test a complete new install and see if it works for you.  You can then 
> move c:\cygwin to c:\cygwin_test and move c:\cygwin_works back to 
> c:\cygwin to restore your old installation.
> 
> Harold
> 
> Jay Smith wrote:
> 
>> Harold,
>>
>> Before I embark on upgrading all of Cygwin to deal with this, is there 
>> any risk that stuff will break?  Since Cygwin underwent a major 
>> overhaul recently, it seems to me that there is a chance that some 
>> small parts of XFree86 stuff (I use little else) might be broken until 
>> all is brought up to speed.
>>
>> Since this is a minute-to-minute critical application (X windowing) 
>> upon which we rely 100%, I have to be very careful about changes.  
>> (Recalling recent RedHat library changes which broke lots of stuff and 
>> recent Perl version changes which wrecked our CGI scripts.)
>>
>> What is the status? Does all the XFree86 stuff work under the new 
>> Cygwin? Is it "safe" now?  (I know that in the first few weeks it was 
>> not "safe".)
>>
>> Jay
>>
>> Harold L Hunt II said the following on 10/14/2003 09:23 PM:
>>
>>> Jay,
>>>
>>> Jay Smith wrote:
>>>
>>>> Harold,
>>>>
>>>> a) Before I attempt this fix, will this work with my old version of 
>>>> everything else?  I know that Cygwin has moved ahead since April.  
>>>> Or does installing this start me down a slippery slope...
>>>
>>>
>>>
>>>
>>> I hate when I forget to ask this if people are running the latest 
>>> version or not.  You really need to be running the latest versions in 
>>> order for us to properly debug and test things.
>>>
>>> Yes, you will have to update to the 4.3.0 release of Cygwin/XFree86.  
>>> I think I released it after April.  All of the DLLs have had their 
>>> names changed, so you need to get those (in the -bin package) but I 
>>> believe I made the fonts in such a way that they will not download 
>>> again unless you have a really old version.  You will basically need 
>>> to get anything that has a new version, since there have been updates 
>>> to Cygwin's DLL, various libraries, etc.
>>>
>>>> b) Before I had the sense to ask the question above, I got as far as 
>>>> starting the download process from a mirror that I had previously 
>>>> used. The  setup program warned me that a newer setup.ini file would 
>>>> replace the old one, but did not seem to give me a way to cancel 
>>>> out.  So, now I have an new setup.ini but old "everything else" 
>>>> files -- and I *do* need the "old everything else" to reinstall on 
>>>> PCs that die, etc.  Am I screwed?
>>>
>>>
>>>
>>>
>>> Setup gives a warning about setup.ini telling it that there is a new 
>>> version of setup.exe available and that you don't have it.  Download 
>>> the latest setup.exe and you won't get the warning (plus there has 
>>> been a lot of development on setup.exe in the last several months).
>>>
>>> I'm not sure about the status of your installation images.  It sounds 
>>> like you have been doing a download to disk then installing from 
>>> that? Uh... guess all I can tell you is that you should have backed 
>>> up first :)  Of course, you could just look at files that have been 
>>> updated recently and check if setup.exe made a backup of the old 
>>> setup.ini that you had.
>>>
>>> Harold
>>>
>>>
>>>> Jay
>>>>
>>>>
>>>> Harold L Hunt II said the following on 10/12/2003 11:01 PM:
>>>>
>>>>> Jay,
>>>>>
>>>>> I just posted XFree86-xserv-4.3.0-20 as a 'test' package; it should 
>>>>> be showing up on mirrors within a few hours.  When it does, run 
>>>>> setup.exe and manually select version '4.3.0-20' for the 
>>>>> XFree86-xserv package. Then, run the new server version as usual 
>>>>> (do not use the new flag that Kensuke talked about) and report your 
>>>>> results to the mailing list.
>>>>>
>>>>> Harold
>>>>>
>>>>> Jay Smith wrote:
>>>>>
>>>>>> Dear Kensuke,
>>>>>>
>>>>>> Thank you very much for your effort on this.
>>>>>>
>>>>>> Unfortunately, I am pretty ignorant of these matters, thus you 
>>>>>> will have to tell me what it is that I should do with the two 
>>>>>> .diff files you attached. I will be happy to do whatever with 
>>>>>> them, but I am clueless as to what is to be done with them.
>>>>>>
>>>>>> Sorry to be a pain.
>>>>>>
>>>>>> Jay
>>>>>>
>>>>>> Kensuke Matsuzaki said the following on 10/12/2003 09:33 PM:
>>>>>>
>>>>>>> Jay,
>>>>>>>
>>>>>>> Perhaps this patch enable XWin to copy/paste non-ascii characters
>>>>>>> even if Windows does't support Unicode (95/98/Me).
>>>>>>> LANG environment variable and Windows locale must be same.
>>>>>>> I added -nounicodeclipboard option, I tested using this on XP.
>>>>>>> But I don't have 95/98/Me.
>>>>>>>
>>>>>>> And it seems tha libX11 has some CTEXT convertion bug, I attach
>>>>>>> patch that based on TAKABE's work.
>>>>>>> http://www.ff.iij4u.or.jp/~t-takabe/xf410_xim_fix.diff
>>>>>>>
>>>>>>> By the way, nls/locale.alias has alias somethig like
>>>>>>> "Arabic_Egypt.1256". Can we use that?
>>>>>>> If so, we no longer need LANG environment variable.
>>>>>>> We can get it following code.
>>>>>>>
>>>>>>>   char pszCountry[128];
>>>>>>>   char pszLanguage[128];
>>>>>>>   int nAcp = GetACP ();
>>>>>>>     GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGCOUNTRY, 
>>>>>>> pszCountry, 128);
>>>>>>>   GetLocaleInfo (LOCALE_SYSTEM_DEFAULT, LOCALE_SENGLANGUAGE, 
>>>>>>> pszLanguage, 128);
>>>>>>>
>>>>>>>   printf ("%s_%s.%d\n", pszLanguage, pszCountry, nAcp);
>>>>>>>
>>>>>>> Kensuke Matsuzaki


-- 
Jay Smith

e-mail: Jay@JaySmith.com  mailto:Jay@JaySmith.com
website: http://www.JaySmith.com

Jay Smith & Associates
P.O. Box 650
Snow Camp, NC  27349  USA

Phone: Int+US+336-376-9991
Toll-Free Phone in US & Canada:
	1-800-447-8267
Fax: Int+US+336-376-6750

Re: results/problems (Re: [PATCH] Copy/Paste non-ascii characters)

[Harold L Hunt II]

Jay,

Jay Smith wrote:
> Harold,
> 
> I have done the installation and I have several things to report. If 
> some of these are not for this list, please advise.  First of all, FYI, 
> when I did the install, Progeny would not respond at all so I used 
> Purdue.  In any case, I turned OFF everything and then turned on only 
> XFree xserve, scalable fonts, and xwinclip -- those of course caused 
> some other things to turn on automatically.
> 
> 1) The main problem of copy/paste of non-ascii characters *within* Linux 
> Mozilla seems to be *fixed*.  Thanks!

That is good to know.  Thanks to Kensuke Matsuzaki.

> However....
> 
> 2) I had my own modified script (with its own unique filename) that was 
> used to start X; I guess this was before startxdmcp.bat was available.  
> I copied my script into place. However, when I run MY script now, it 
> seems like the command (in MY script)
>    start XWin -nodecoration -clipboard -once -query jsa.jaysmith.com
> actually (also?) RUNS startxdmcp.bat
> 
>    That is very odd and I am not sure what to do.  I had to modify 
> startxdmcp.bat to bring it in line with my script so the proper command 
> would get done.
> 
>    I believe that startxdmcp.bat is getting run because the DOS box that 
> appears says so, identifying it by name -- even if *I* don't directly 
> run it.

You would have to send in your script and your copy of startxdmcp.bat 
and the exact command you are using to run your script in order for us 
to figure out what is going on.

> 3) I think that startxdmcp.bat may have an error in it.  The original 
> version of it has the command:
> 
>       start XWin -query %REMOTE_HOST% -nodecoration -lesspointer
> 
>    and this causes an error in the DOS box about "too many paramaters". 
> I am certainly no expert, but I think that the "-query ...." should be 
> the LAST thing on the command line.  Anyway, when I made it so (like my 
> original script) it worked without putting out the error.

Nope.  The order of these parameters shouldn't matter.  You may be 
having some trouble if %REMOTE_HOST% is not properly defined or if it 
has characters in it that are getting interpreted by the DOS batch 
processor.

> 4) Generally X performance seems to be better.  It is very subjective, 
> but so good, so far.

Huh... no performance tweaks this time.  Must just feel faster :)

Harold