JDK-6474139 : Left and right most characters in JTextField is getting chopped
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.2
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2006-09-22
  • Updated: 2011-04-28
Related Reports
Relates :  
Description
FULL PRODUCT VERSION :
JRE 1.4.2 and 1.5.0_06

ADDITIONAL OS VERSION INFORMATION :
WINDOWS 2000 and XP

A DESCRIPTION OF THE PROBLEM :
When the font of the text field field is set to "Courier New" Bold and 12 pts, The following problems are observed.

1. The text in the left and right most characters are getting cut partially.
2. When we select the text using mouse the text is dancing left and right.


STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :

The following are the conditions where this behaviour is observed:

1. Certain wide characters like M, R and W which are chopped when they occur at the left and right edges.
2. The text field is filled to its capacity interms of number of characters.
3. Only for MONOSPACE fonts (we are using "Courier New"  font).
4.  BOLD and 12 pts



Following is the code to reproduce the above problems.

public class FontTest
{
	public static void main(String[] a)
	{
		javax.swing.JFrame testFrame = new javax.swing.JFrame("Test");
		testFrame.setBounds(320,320,150,150);
		
	    		testFrame.getContentPane().setLayout(new FlowLayout());
                JTextField field=new JTextField("MTEXTR");
                field.setColumns(6);
                field.setFont(new Font("Courier New",Font.BOLD,12));
                field.setEditable(false);
                field.setEnabled(false);
                field.setDisabledTextColor(Color.BLACK);
                
                testFrame.getContentPane().add(field);
		        testFrame.setDefaultCloseOperation(javax.swing.JFrame.EXIT_ON_CLOSE);
                testFrame.setVisible(true);
	}
}


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.Color;
import java.awt.FlowLayout;
import java.awt.Font;

import javax.swing.JTextField;


public class FontTest
{
	public static void main(String[] a)
	{
		javax.swing.JFrame testFrame = new javax.swing.JFrame("Test");
		testFrame.setBounds(320,320,150,150);
		
	    		testFrame.getContentPane().setLayout(new FlowLayout());
                JTextField field=new JTextField("MTEXTR");
                field.setColumns(6);
                field.setFont(new Font("Courier New",Font.BOLD,12));
                field.setEditable(false);
                field.setEnabled(false);
                field.setDisabledTextColor(Color.BLACK);
                
                testFrame.getContentPane().add(field);
		        testFrame.setDefaultCloseOperation(javax.swing.JFrame.EXIT_ON_CLOSE);
                testFrame.setVisible(true);
	}
}
---------- END SOURCE ----------

Comments
EVALUATION Two problems of JTextField are described: 1. The text in the left and right most characters are getting cut partially. 2. When we drag mouse over disabled uneditable JTextField the text is dancing left and right. I know the cause of the first problem and don't have an idea about the second one. I think it is for the Swing Text Team. To avoid the text clipping we should take in account left and right side bearings for the text (see 6464003). Now only the left one is used (see FieldView.getPreferredSpan()) and it is calculated only for the 'W' character. I tried this approach and found that the text isn't clipped at the left, but still clipped at the right. If you move caret to the right, the text won't be clipped. Such behavior caused by a "wrong" preferred size of JTextField. It's width is based on the column count and average width of a character. Frequently real text width is wider than calculated preferred one and we see that the text is clipped at the right. The text clipping problem for the right side cannot be fixed in the bounds of the current API when you can specify number of columns for JTextField. Workaround is simple: specify more columns (+1) than it is actually needed.
19-10-2006

EVALUATION I'll make sure this bug is fixed along with 6464003 -- they seem closely related indeed.
28-09-2006