Thank you again.
I guess this means that I cannot stop it? I wanted to print a 16 bit integer.
Well, now that you know that the Print class will automagically cast to a long, combined with the observation that leading zeros are trimmed, try padding your ints with an MSint of zeros and send that resulting long to Print. (i.e. if you want to print 0xF3AD, pad it to get 0x0000F3AD and print that long.) Might work, might not.
Seems to me to be a bug in the Print class though because your experimentation shows that there is no way to predict what the new 16 bits will be that the Print class pads when it casts the input int as a long. Actually, the pattern seems to be the new 16 bits will be the same value as your MSbit, but without more statistics I can't say if that is actually happening, or coincidence... Thinking more about it, I wonder if it's because int is signed, and all those extra binary ones are appropriate for 'zero padding' a negative number... What happens if you try to pass an unsigned 0xFFFF to the Print class?