The FontMetrics.charwidth method is returning a non-zero width result for zero width characters such as \u202d. This is the cause of the following problem reported by Makoto Kanda of Oracle. This is possibly also the cause of regression bug 4514652.


Makoto writes:

I'd like you to make sure that Java guarantees that the \u202d is
always drawn as a 0 width character, regardless the font or the
font.properties. I see some problems when I display Arabic with \u202d
(e.g. "\u202d\ufef2\ufe91\ufeae\ufecb") on Japanese Windows 2000, with
the default font.properties.ja (see below).

<How to reproduce the problem described in the above #3>
1. Run the attached test case on Japanese Windows 2000. You'll get
something like 0.jpg.

2. Press the Right arrow key 4 times. You'll get something like 4.jpg.

3. Press another Right arrow key. You'll get something like 5.jpg which
is not correct.

4. Press the Shift+Left key once. You'll get something like 6.jpg which
is not correct.

Thank you.

Regards,

- Makoto

    ---------------------------------------------------------------------
import javax.swing.JFrame;
import javax.swing.JTextField;
import java.awt.BorderLayout;

import java.awt.AWTEvent;
import java.awt.event.WindowEvent;

public class Bidi202DTest extends JFrame
{
  public Bidi202DTest()
  {
    setTitle("Explicit 202D Bidi Test");

    enableEvents(AWTEvent.WINDOW_EVENT_MASK);

    JTextField jtf = new JTextField("\u202d\ufef2\ufe91\ufeae\ufecb");
// JTextField jtf = new JTextField("\u202dCBA");

    getContentPane().add(jtf, BorderLayout.CENTER);

    pack();
    setVisible(true);
  }

  protected void processWindowEvent(WindowEvent e)
  {
    super.processWindowEvent(e);
    if (e.getID() == WindowEvent.WINDOW_CLOSING)
    {
      setVisible(false);
      System.exit(0);
    }
  }

  public static void main(String[] args)
  {
    new Bidi202DTest();
  }
}