scjones@thor.UUCP (Larry Jones) (09/27/90)
We're currently porting the X client libraries to an IBM mainframe
which speaks EBCDIC instead of ASCII (or ISO Latin-1 if you prefer).
Xlib and Xt are basically working, but we're having some difficulty
trying to decide how to handle the character set difference. Since
we just ignored the issue to start with, a typical client ends up
with its resource names in EBCDIC, which match the resources being
read from its app defs file, but not the (ASCII) server resources.
Also, window properties like the application name are in EBCDIC
where the server expects ASCII. Similarly for things like color
and font names.
If the conversion is the application programmer's responsibility
as implied by the Xlib documentation that requires ISO Latin-1
for things like font and color names, then what's Xt and a widget
writer to do? Must Xt convert all the resource files it reads
into Latin-1? Must a widget writer specify all resource names
in Latin-1? All of the predefined resources are simply printable
character strings like "font" which is a whole lot more readable
and easier to use than "\146\157\156\164" which is the only way
to guarantee a Latin-1 encoding. Since these strings are used to
initialize data structures, they have to be constants so you can't
even use something like LocalToLatin1("font").
Any guidance would be greatly appreciated.
----
Larry Jones UUCP: uunet!sdrc!thor!scjones
SDRC scjones@thor.UUCP
2000 Eastman Dr. BIX: ltl
Milford, OH 45150-2789 AT&T: (513) 576-2070
Even though we're both talking english, we're not speaking the same language.
-- Calvinrws@EXPO.LCS.MIT.EDU (Bob Scheifler) (09/27/90)
Boy, am I glad you asked that question. :-) We've recently been discussing this issue at some length inside the X Consortium, as part of our work on internationalization. The problem is not really part of internationalization, but I view the root of the problem and the piece of the solution as the same. We're currently working along the lines of having Xlib do all conversions automatically under the covers, so that you can continue to use string literals and EBCDIC files, and have everything work out reasonably well. I won't guarantee you this is how things will be specified, but I think that's where we're headed. In the meantime, are you sure IBM doesn't have an Xlib product you can buy? Because I suspect their Xlib, if they have it, is already reimplemented to do such conversions.
pierce@CAMBRIDGE.IBM.COM ("J. Andrew Pierce") (10/01/90)
IBM does in fact have TCP/IP products for both VM and MVS which include
support for X. The way it is handled is that calls to Xlib routines
pass EBCDIC strings, which are converted for the user to ISO Latin-1.
Strings returned from the X server are converted to EBCDIC as well.
It turns out that there are only a limitied number of places where
the conversion needs to be done and a bit of code that could be
portable but was not coded that way (XOpenDisplay, for example, which
uses character constants for client.byteOrder where it could and
should use the actual hex values). There are also some examples in
the Intrinsics where hex values are used where character constants
would be more portable. There are a couple of examples where the
Xlib routines try to be real efficient and write the data directly
from the user data. In these cases, the code uses a buffer to
copy a translated version of the data before writing it.
I'm glad to see the X Consortium considering this!
Andy Pierce