More specifics, Re: Anybody familiar with Java on MacOS-X?

["James H H Lampert" <jamesl@xxxxxxxxxxx>]

I wrote:
> Our TN5250E client (the one that's somehow become the 
> most-used function of our ThinView product, and that's 
> also bundled in our Wintouch product) is having a weird 
> rendering problem when run on a Mac. Things that line up 
> perfectly under all WinDoze JVMs don't line up at all 
> under Mac JVMs.

A source fragment might help make this a bit less vague:

"ch" is the EBCDIC value of the character to be rendered.
"bgr" is the Graphics context we're drawing into.
"chw" and "chh" are the width and height of a character 
cell, based on font scaling, the last time the window was 
resized. I don't recall clearly what "chd" is, but I think 
it's the character descent, or something similar.
"col" and "row" are the character position on the emulated 
terminal window, with col being from 1 to 80 (or 132), and 
row being from 1 to 24 (or 27).
"isField" indicates whether we're in a field, and 
"renderBorders" indicates whether fields are to have 
GUI-look borders, instead of 5250-style underscoring.

if (ch == 28) {
    bgr.drawString("*", (col - 1) * chw, row * chh - 
chd);
    bgr.drawString(String.valueOf((char)175), (col - 1) * 
chw, row * chh - chd);
} else if (ch == 240) {
    bgr.drawString("0", (col - 1) * chw, row * chh - 
chd);
    bgr.drawLine((int)((col-1) * chw + (chw * .45)), 
(int)((row-1) * chh + (chh * .45)), (int)((col-1) * chw + 
(chw*.45)), (int)((row-1) * chh + (chh * .55)));
} else if (ch != 0) {
    ch = toAscii[ch];
    if (ch == '_') bgr.drawString("_", (col - 1) * chw, 
(row * chh - chd) - 2);
    else  bgr.drawString(String.valueOf(ch), (col - 1) * 
chw, row * chh - chd);
}
if (underline && (!isField || !renderBorders)) {
    bgr.drawLine((col - 1) * chw, row * chh - 2, col * 
chw - 1, row * chh - 2);
    bgr.setColor(backColor);
}

And that's about all I can share (to coin a phrase, "I 
could tell you more, but then I'd have to kill you").

At any rate, everything rendered with drawLine calls seems 
to be in the right place, but everything rendered with 
drawString calls seems to be shifted, as if coordinates 
were multiplied by some factor (order of 2) coming out of 
left field. And again, the malfunction only seems to be 
occurring on Macs; Windoze boxes seem fine.

Again, I'd prefer to limit the on-list traffic, since this 
is still only peripherally on-topic, so I'd prefer private 
replies; I'll share the solution (or at least, all 
non-confidential parts of the solution), if and when it 
turns up, with anybody else who's interested.
 
--
JHHL