Geren,
I'm not familiar with right-to-left intermixed with left-to-right, but I have done a lot with spooled files and java and double-byte character sets. So let me offer a few suggestions:
There are lots of transformations going on here, not just the one done by the Bidi classes. The javadoc for AS400BidiTransform states that the " class provides layout transformations that allow the conversion of Bidi text in AS/400 format (after its conversion to Unicode) to Bidi text in Java format, or vice-versa ". That conversion to Unicode is not simple.
RPG deals with text in what is equivalent to java byte arrays. Every one of those byte arrays has a CCSID. RPG does lots of work to convert everything it reads from tables or files or streams into its internal character fields into the CCSID of the job. It has to do that so comparisons between field vales work as the RPG programmer expects. Before you put that byte array stuff into AS400BidiTransform, it has to be converted into a java string; that is, it must be converted from the byte array to Unicode using some CCSID. So the first place to check is to see if the java string is properly converted to Unicode. Apparently it is at least pretty close as you don't complain about characters not being changed properly, just the order of the characters.
Second place to look is to see whether the characters are going into those RPG byte arrays properly. How is the RPG reading the spooled file? SCS spooled files use an ancient 3270 stream format that employs SHIFT-IN, SHIFT-OUT characters to switch back and forth to double-byte character set data. I think Hebrew is single-byte so that probably isn't an issue, but the old format does something weird for switching back and forth between LTR and RTL, too. It'll take some study to figure this out. If you are using CPYSPLF to get the spooled file into a database file, study the database file and see if the problem is there.
Let us know what you find.
DK
-----Original Message-----
From: java400-l-bounces@xxxxxxxxxxxx [mailto:java400-l-bounces@xxxxxxxxxxxx] On Behalf Of Geren White
Sent: Friday, June 28, 2013 3:58 PM
To: java400-l@xxxxxxxxxxxx
Subject: Sending Hebrew data from RPG program to Java program
Hello All,
I'm having some issues with handling Hebrew data that I was hoping some of you might be able to help me out on. I'm trying to send Hebrew data from an RPG program to a Java program which the Java program then takes and constructs a PDF. I'm having a few issues with processing the Hebrew data to get it into a correct display order. I'm the Java programmer on this project so please excuse any iSeries/RPG ignorance.
So first off the RPG program sends a string of data to the Java program that is a mix of Hebrew/English/numerical data. The data comes from a spooled file on the iSeries and is actually each line of the file. There is no processing of the data on the iSeries side and it is sent as is. The Java program is receiving most of the data as I would expect in a logical order. Logical order being the order in which the characters were typed.
I've used the Java Bidi class to process the data and I've tried the AS400BidiTransform class. Both of these classes can handle most of the data correctly and get it into a correct display order. The issue is that there are certain strings of data that are received in an unexpected order.
This is best explained through examples so assume capital H's are Hebrew:
An example of a situation that can be handled by the Java Bidi class or
AS400BidiTransform:
First the correct display order:
english :HHHH
I would receive this string as:
HHHH: english
The first H in the received string would be the right most H in the display order. As you can see this would be a logical order for bidirectional data as the user would type the Hebrew and then switch to LTR with the english portion. There are much more complex situations that are handled correctly by the Bidi classes as well but this is just a simple example.
Now an example of an incorrect ordering:
Correct display order:
350 X 250 X 150 :HHHH
Received order:
HHHH: 150 350 X 250 X
This data does not seem to be in a logical order. The first number after the Hebrew, 150 in this case, seems to stay within the RTL segment while the rest of the equation gets put into a LTR segment. The Java Bidi class and the AS400BidiTransform class do not process this correctly. There are many more situations where this happens and way too many to have special cases for.
I've been reading all about bidirectional data processing and iSeries support for it and can't seem to figure this out. I'm thinking it might be an issue with the CCSID on the iSeries. The system's CCSID is 65535 and all our jobs should be the same. So from my understanding there shouldn't be any conversion on the iSeries side but somewhere along the line this data is getting jumbled.
If any of you have any experience with this or any ideas they would be much appreciated. Let me know if you need more information. Thank you for your time.
Regards,
Geren White
CYBRA Corporation
--
This is the Java Programming on and around the IBM i (JAVA400-L) mailing list To post a message email: JAVA400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/java400-l
or email: JAVA400-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at
http://archive.midrange.com/java400-l.
midrange.com
