Skip to main content

[JAVA2D] Return of the Killer Glyph - How one glyph kills them all

4 replies [Last post]
Anonymous

Yesterday I ran into an amazing behaviour in glyph rendering. This
probably qualifies as a bug, but in any case it is really weird.

In a few words, if one certain glyph is displayed in a JTextField (or
generally in Swing text), it will kill all trailing glyphs (or at least
make them disappear)! This probably only works on Windows (I tested this
on WinXP running JRE 1.6b66 and JRE 1.5), because Wingdings must be used
for the characters uf000 - uf0ff.

So if you are running Windows, simply run the attached test class. When
you press on the button, character uf0ea, which is rendered using the
Wingdings "bold arrow down", will be inserted at the beginning of the
text in the JTextField (it should be a bold down arrow, otherwise you
probably will not see the effect). Suddenly all trailing characters
disappear. If you remove the character (simply by editing the
JTextField), the characters will reappear. Isn't this weird? And if you
select the killer glyph, only the directly following glyph will be visible.

What actually seems to happen is that the followings glyphs are still
there, but they are shifted up, outside of the visible rect of the
JTextField. And there are other glyphs in Wingdings, that can shift the
trailing glyphs down (for example uf0ea), neutralizing the effect. And
using two of the glyphs shifts the trailing chars twice (so you need two
gylphs shifting into the other direction to neutralize the effect). This
has probably something to do with the inserted glyph's baseline, but it
is strange that the leading glyphs are displayed normally.

I have seen similar effects with our text editor in some cases, when
whole lines were shifted behind some weird glyphs, but this is the first
time that I found something that I can actually put my fingers on.
Actually I am not really sure what to make of this. Is it the correct
behaviour from an engineer's point of view (it certainly is not from a
user's point of view). Is it a bug? Should I file a bug report? Also, is
this a Java2D related issue, or is the Swing team responible here?

Cheers

Jan

************* start of test class *****************

import javax.swing.*;
import java.awt.*;
import java.awt.event.ActionListener;
import java.awt.event.ActionEvent;

public class KillerGlyphTest {

public static void main(String[] args) {
final JTextField textField = new JTextField("Text to be killed");
JButton button = new JButton("Insert Killer Glyph");
button.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
// We simply insert one character at the beginning of the text
textField.setText('\uf0ea' + textField.getText());
}
});
// add button and text field to a panel
JPanel panel = new JPanel(new BorderLayout());
panel.add(textField, BorderLayout.NORTH);
panel.add(button, BorderLayout.CENTER);
// create a frame and show it
JFrame frame = new JFrame("Return of the Killer Glyph");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setContentPane(panel);
frame.setSize(300, 100);
frame.validate();
frame.setLocationRelativeTo(null);
frame.setVisible(true);
}

}

************* end of test class *****************

Just for completeness, here is an incomplete list of glyphs from
Wingdings that show a similar behaviour (as you can see they are all
gylphs used for to display up/down metaphor):

- uf0e9 (shifts trailing text down, this can neutralize uf0ea)
- uf0ce (shifts trailing text down)
- uf0cf (shifts trailing text up)
- uf0dd (shifts trailing text down)
- uf0de (shifts trailing text up)
- uf0f1 (shifts trailing text down)
- uf0f2 (shifts trailing text up)
- uf047 (shifts trailing text down)
- uf048 (shifts trailing text up)

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
stanislavl
Offline
Joined: 2003-06-17

Hi Phil,

I think it's a bug anyway. I tried to insert the chars in e.g. MS Word and don't see described behaviour. All the chars are set in one line. The advance mustn't be accumulated.

Hope such cases will be included in bug list.

regards,
Stas

philrace
Offline
Joined: 2003-06-09

Sorry for taking so long to get round to replying to
this. yes we need to do something about this.
I've filed bug 6467483.

Phil Race

For that character we are reporting a vertical advance as well as an horizontal advance.
There seem to be a few in wingdings that do so - probably those you identify.
It would take some digging to see if we are reporting correctly.

-phil.

Jan Bösenberg (INCORS GmbH) wrote:
> Yesterday I ran into an amazing behaviour in glyph rendering. This
> probably qualifies as a bug, but in any case it is really weird.
>
> In a few words, if one certain glyph is displayed in a JTextField (or
> generally in Swing text), it will kill all trailing glyphs (or at least
> make them disappear)! This probably only works on Windows (I tested this
> on WinXP running JRE 1.6b66 and JRE 1.5), because Wingdings must be used
> for the characters uf000 - uf0ff.
>
> So if you are running Windows, simply run the attached test class. When
> you press on the button, character uf0ea, which is rendered using the
> Wingdings "bold arrow down", will be inserted at the beginning of the
> text in the JTextField (it should be a bold down arrow, otherwise you
> probably will not see the effect). Suddenly all trailing characters
> disappear. If you remove the character (simply by editing the
> JTextField), the characters will reappear. Isn't this weird? And if you
> select the killer glyph, only the directly following glyph will be visible.
>
> What actually seems to happen is that the followings glyphs are still
> there, but they are shifted up, outside of the visible rect of the
> JTextField. And there are other glyphs in Wingdings, that can shift the
> trailing glyphs down (for example uf0ea), neutralizing the effect. And
> using two of the glyphs shifts the trailing chars twice (so you need two
> gylphs shifting into the other direction to neutralize the effect). This
> has probably something to do with the inserted glyph's baseline, but it
> is strange that the leading glyphs are displayed normally.
>
> I have seen similar effects with our text editor in some cases, when
> whole lines were shifted behind some weird glyphs, but this is the first
> time that I found something that I can actually put my fingers on.
> Actually I am not really sure what to make of this. Is it the correct
> behaviour from an engineer's point of view (it certainly is not from a
> user's point of view). Is it a bug? Should I file a bug report? Also, is
> this a Java2D related issue, or is the Swing team responible here?
>
> Cheers
>
> Jan
>
>
>
>
> ************* start of test class *****************
>
> import javax.swing.*;
> import java.awt.*;
> import java.awt.event.ActionListener;
> import java.awt.event.ActionEvent;
>
> public class KillerGlyphTest {
>
> public static void main(String[] args) {
> final JTextField textField = new JTextField("Text to be killed");
> JButton button = new JButton("Insert Killer Glyph");
> button.addActionListener(new ActionListener() {
> public void actionPerformed(ActionEvent e) {
> // We simply insert one character at the beginning of the text
> textField.setText('\uf0ea' + textField.getText());
> }
> });
> // add button and text field to a panel
> JPanel panel = new JPanel(new BorderLayout());
> panel.add(textField, BorderLayout.NORTH);
> panel.add(button, BorderLayout.CENTER);
> // create a frame and show it
> JFrame frame = new JFrame("Return of the Killer Glyph");
> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
> frame.setContentPane(panel);
> frame.setSize(300, 100);
> frame.validate();
> frame.setLocationRelativeTo(null);
> frame.setVisible(true);
> }
>
> }
>
>
> ************* end of test class *****************
>
>
> Just for completeness, here is an incomplete list of glyphs from
> Wingdings that show a similar behaviour (as you can see they are all
> gylphs used for to display up/down metaphor):
>
> - uf0e9 (shifts trailing text down, this can neutralize uf0ea)
> - uf0ce (shifts trailing text down)
> - uf0cf (shifts trailing text up)
> - uf0dd (shifts trailing text down)
> - uf0de (shifts trailing text up)
> - uf0f1 (shifts trailing text down)
> - uf0f2 (shifts trailing text up)
> - uf047 (shifts trailing text down)
> - uf048 (shifts trailing text up)
>
> ===========================================================================
> To unsubscribe, send email to listserv@java.sun.com and include in the body
> of the message "signoff JAVA2D-INTEREST". For general help, send email to
> listserv@java.sun.com and include in the body of the message "help".

===========================================================================
To unsubscribe, send email to listserv@java.sun.com and include in the body
of the message "signoff JAVA2D-INTEREST". For general help, send email to
listserv@java.sun.com and include in the body of the message "help".

jansan
Offline
Joined: 2005-02-24

Thanks for the information.

I tried to find out a little more on this issue and created a little tool that shows all characters of all fonts on my system that have a vertical advance. The result was that beside Wingdings, only a handfull of other fonts contain (usually very few) glyphs that have vertical advance. There are no glyphs that have only a vertical advance (if there is a vertical advance, there also is a horizontal advance). And other than I expected, these fonts and glyphs are not related to CJK or complex layout. For example the font "Comic Sans MS" contains exactly one single glyph with a vertical advance, which is the small 'c' with a circumflex (u0109).

Then I compared the text layout of Java with the layout of other applications (MS Word, OpenOffice, some graphics apps like Photoshop and Paint Shop Pro). In the test case consisted of drawing a string of five "c-circumflex" with Comic Sans MS. While with Java the glyphs are ascending (each glyph is a little bit shifted upwards compared to the previous), all other applications align them on a horizontal line. (I tried to attach an image showing the results, but somehow my emails never appeared in this mailing list).

Now it is still unclear to me if this is a bug or not. My uneducated guess is that while the reported GlyphMetrics are correct, the GlyphVector and TextLayout should either use the horizontal advance (for horizontal layout) or the vertical advance (for vertical layout, which is sometimes used in Japanese and Chinese), but not both at the same time. I cannot think of a real word situation that requires the horizontal AND vertical advance at the same time. In any case, the current behaviour looks very strange to me and it is certainly different from other applications' behaviour.

So do you think this is a bug?

Cheers

Jan

P.S.: Did you receive the email containing the image showing the c-circumflexes?