Xref: utzoo comp.windows.x.motif:932 comp.windows.x:28306
Path: utzoo!attcan!uunet!timbuk!cs.umn.edu!ub.d.umn.edu!rutgers!cs.utexas.edu!sun-barr!ccut!wnoc-tyo-news!scslwide!wsgw!wsserva!ogawa
From: ogawa@sm.sony.co.jp (Masato Ogawa)
Newsgroups: comp.windows.x.motif,comp.windows.x
Subject: Re: Trouble using Motif's XmText widget with k14 Kanji Font
Message-ID: <OGAWA.90Oct16194207@actor.sm.sony.co.jp>
Date: 16 Oct 90 10:42:07 GMT
References: <1431@quintus.UUCP>
Sender: news@sm.sony.co.jp
Followup-To: comp.windows.x.motif
Organization: Workstation Div., Sony Corp., Japan
Lines: 22
In-reply-to: dimitar@quintus.UUCP's message of 5 Oct 90 23:14:24 GMT

In article <1431@quintus.UUCP> dimitar@quintus.UUCP (Dimitar Bojantchev) writes:
 > I am unable to display text in the XmText widget if I set the font to
 > k14, (two byte, Japanese font).  Looking through the sources of the
 > text widget it seems that it should handle 16 bit characters, at least
 > there is code to invoke XDrawImageString16 to draw the text.  It seems
 >  	:

No. I'm looking the source in few days (and more), there is not the
right implementation for 16bit code in XmText.
XmText works with "block" structure as you know, but everywhere to set
string data into the structure, block.format is set to FMT8BIT.
So every data are treated as "roman".
  In some places, there are codes for FMT16BIT, but I think they
haven't tested. For example, the "Draw" routine in TextOut.c, the x value
of XDrawImageString16 must be offseted by hoffset of XmText, but not
(refer to the FMT8BIT portion in that routine to know how it should be
written	).
So, If you could set FMT16BIT data into XmText, Kanji's are never
scrolled horizontally. 

And more essential question: How to treat mixed sentense with Kanji
and roman alphabet with XmText...