-
Bug
-
Resolution: Fixed
-
P4
-
1.4.0
-
b45
-
generic
-
generic
The java.awt.Graphics.drawBytes() method has never specified how it interprets
the byte data. The java doc does not say what encoding it will use to convert
bytes to characters.
So an implementation might
- interpret the bytes as 8-bit ASCII
- interpret the bytes as UTF-8
- interpret the bytes using the default (host) encoding
- let the underlying rendering system interpret the bytes, which probably,
but not necessarily, equates to the host encoding.
The closest there was sot a specification is that JDK 1.1.X in shared code
interpreted the data as ASCII.
But the X11 (Solaris) and win32 subclasses over-rode this to use platform
encoding (ie the 4th option above)
JDK 1.2 and later still have the shared code definition which interprets
the data as ASCII and the new 2D implementation (presumably) referenced
the shared code definition and interpreted it as 8-bit ASCII.
The platform spec should document the encoding that is used.
the byte data. The java doc does not say what encoding it will use to convert
bytes to characters.
So an implementation might
- interpret the bytes as 8-bit ASCII
- interpret the bytes as UTF-8
- interpret the bytes using the default (host) encoding
- let the underlying rendering system interpret the bytes, which probably,
but not necessarily, equates to the host encoding.
The closest there was sot a specification is that JDK 1.1.X in shared code
interpreted the data as ASCII.
But the X11 (Solaris) and win32 subclasses over-rode this to use platform
encoding (ie the 4th option above)
JDK 1.2 and later still have the shared code definition which interprets
the data as ASCII and the new 2D implementation (presumably) referenced
the shared code definition and interpreted it as 8-bit ASCII.
The platform spec should document the encoding that is used.