Unicode support in AWT

General Discussions
#1

It appears that on PCs, unicode support is incomplete in AWT. Specifically for Cyrillic and Japanese strings displayed by java.awt.Button and java.awt.Popupenu. The text appears as blocks rather than the correct glyphs. The same strings display correctly in most other circumstances.

Some data points: Using the same font/size

if we set the label of a java.awt.Button to “Отправить” it displays as blocks.
if we add an item “Отправить” to a java.awt.PopMenu it displays as blocks
if we display “Отправить” on java.awt.Canvas it looks fine.
if we set the label of a javax.swing.JButton to “Отправить” it is also fine.
if we add an item “Отправить” to a javax.swing.JPopupMenu it displayes fine.

So, my question, is there any workaround, or do I just have to convert my whole environment to swing compoennts?

Oh, and also, all of the above examples work fine on a Mac using safari.

#2

The font has to support the glyphs.

Try “ms mincho”.

In Swing you’ll find exactly the same problem, requiring to use specific Japanese (or whatever) fonts

#3

This is not a font support issue. The attached snapshot shows the font displaying
Cyrillic correctly in a canvas, and incorrectly in a popup menu. Alsp, as stated, the
same program displays correctly if I switch the component from PopupMenu to JPopupMenu

#4

Are you sure the fonts in PopupMenu and JPopupMenu are exactly the same?

#5

I tell you three times.

#6

I can reproduce it.

It seems this is the difference between g.drawString() and letting the OS do it (AWT peers). My guess is that there is nothing any Java code can do about that.

If you’d have access to a Japanese version of Windows XP, it would be interesting to see what the AWT peers make of it.

#7

I experimentally converted my popup menus from AWT to swing, and that fixed the
problem with fonts. However, swing menus have two sets of pathologies all their
own.

(1) deployed as a JMenuBar, JMenus display normally if the frame has never been
resized, but after resizing, they are clipped to the bottom of an internal component
of the frame.
(2) deployed as a JPopupMenu, the menus sometimes fail to appear, sometimes
appear as a blank gray box, and sometimes appear as a partially filled blank box
which gradually fills in as you move the mouse over it.

Jeesh! these have only been available for 10 years, one would think it would
be safe to use them by now!

#8

Try

JPopupMenu.setDefaultLightWeightPopupEnabled(false)

#9

Indeed, this seems to fix the clipping problem. I found some discussion elsewhere
of lightweight vs heavyweight menus mixing lightweight vs heavyweight components http://developer.novell.com/tech/684.html.

The component the menu disappears behind is a java.awt.Canvas, for which there is no
swing equivalent.

#10

If you don’t need a native handle (and you probably don’t) you can override JPanel and draw on it just like on a Canvas.

#11

This is the death of 1000 cuts. I’ve already experimented with that. The problem there is
that my interface goes “flash flash” when it updates. Probably related to the fact that I don’t
draw during the normal “paint” message but as part of the run loop.

#12

Yeah, JPanel is double-buffered and doesn’t really like ‘direct access’ using getGraphics().

If you really want to use getGraphics() you can render to your own BufferedImage instead and blit that to the JPanel. Sure, it’s a bit slower, but you can probably spare a few milliseconds.