Skip to main content

Graphics.drawBytes; bug or feature?

3 replies [Last post]
zander
Offline
Joined: 2003-06-13
Points: 0

Hi, in some old code I have the following construct:

g.drawBytes(myString.getBytes(), 0, x, 0, fm.getAscent());

I only recently found that if the myString holds non latin1 characters this produces bugs (squares in the spot where the chars should be).
I changed it to
g.drawString(myString.substring(0, x), 0, fm.getAscent());

Irrelevant if the last code snippit is more correct or not; is it not a bug that the former failed to render chars like the ë (ë ) correctly?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
mthornton
Offline
Joined: 2003-06-10
Points: 0

String.getBytes() encodes the string using the current default character encoding. If that encoding can't represent some characters in your string then you will get some replacement character which may be what you are seeing. A square would be a typical 'replacement'.
I'm a bit surprised that Graphics.drawBytes hasn't been deprecated.

zander
Offline
Joined: 2003-06-13
Points: 0

> String.getBytes() encodes the string using the
> current default character encoding. If that encoding
> can't represent some characters in your string then
> you will get some replacement character which may be
> what you are seeing. A square would be a typical
> 'replacement'.

any encoding but latin1 will support the suggested glyph, a java byte is 16 bits so I have a hard time believing this to be an edequate explenation (i.e. telling me this is expected behavior).

Notice that I have seen said behavior on a Linux machine and on a Windows machine; both have very different default encodings IIRC.

mthornton
Offline
Joined: 2003-06-10
Points: 0

Unfortunately the documentation for Graphics.drawBytes is silent about what encoding it is expecting. We can only hope that it also uses the platform default encoding and doesn't merely zero extend or use some other scheme.