[
https://issues.apache.org/jira/browse/NETBEANS-4533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien DE GEORGES updated NETBEANS-4533:
----------------------------------------
Description:
Scenario:
* Use the Windows Look and Feel in your Java application (with Metal: no
problem).
* Create a ETable with a column header having characters in Chinese or
Japanese (or any not supported by Tahoma font).
* When running the program, click on this header to sort the column => these
characters will be replaced by a square.
(small Maven project attached, with 1 class and one main method)
Root cause:
The headers of the sorted columns will be rendered in bold by the ETable,
which is done in "ETableHeader::getTableCellRendererComponent". This code takes
the font of the JLabel used for the rendering, and creates a similar font in
bold. For that, it does not uses "Font::deriveFont(...)" (because of a 2005 bug
with Apple's JVM), but uses "(new Font (label.getFont().getName(), ...)".
Under Windows it is a problem:
* the default font (used here by the JLabel) is a composite font
* from what I understand, a composite font is a list of physical fonts, which
will be successively used to try to render a given character.
* this list of the physical fonts contains one that supports Chinese
characters.
* label.getFont().getName() retrieves the name of the first font of the
composite font, in the case of the Windows Look and Feel it is "Tahoma" (which
does not support Chinese).
* so the "new Font(...)" used as a header renderer will be only "Tahoma",
hence the square characters.
The suggestion is to revert the patch from 2005 as it is not reproductible
anymore (change of JRE)
Old code:
// don't use deriveFont() - see #49973 for details
label.setFont (new Font (label.getFont ().getName (), Font.BOLD, label.getFont
().getSize ()));
New code:
label.setFont(label.getFont().deriveFont(Font.BOLD));
A patch is attached in the ticket.
Please note that this is a duplicate of a bug already logged in the old
Bugzilla : [https://bz.apache.org/netbeans/show_bug.cgi?id=270091]
was:
Scenario:
* Use the Windows Look and Feel in your Java application (with Metal: no
problem).
* Create a ETable with a column header having characters in Chinese or Japanese
(or any not supported by Tahoma font).
* When running the program, click on this header to sort the column => these
characters will be replaced by a square.
(small Maven project attached, with 1 class and one main method)
Root cause:
The headers of the sorted columns will be rendered in bold by the ETable, which
is done in "ETableHeader::getTableCellRendererComponent". This code takes the
font of the JLabel used for the rendering, and creates a similar font in bold.
For that, it does not uses "Font::deriveFont(...)" (because of a 2005 bug with
Apple's JVM), but uses "(new Font (label.getFont().getName(), ...)".
Under Windows it is a problem:
* the default font (used here by the JLabel) is a composite font
* from what I understand, a composite font is a list of physical fonts, which
will be successively used to try to render a given character.
* this list of the physical fonts contains one that supports Chinese characters.
* label.getFont().getName() retrieves the name of the first font of the
composite font, in the case of the Windows Look and Feel it is "Tahoma" (which
does not support Chinese).
* so the "new Font(...)" used as a header renderer will be only "Tahoma", hence
the square characters.
Does this analysis makes sense for you?
My suggestion would be to revert the patch from 2005. I don't have a Mac to my
disposition to test that its works though.
Old code:
// don't use deriveFont() - see #49973 for details
label.setFont (new Font (label.getFont ().getName (), Font.BOLD, label.getFont
().getSize ()));
New code:
label.setFont(label.getFont().deriveFont(Font.BOLD));
A patch is attached in the ticket.
Please note that this is a duplicate of a bug already logged in the old
Bugzilla : [https://bz.apache.org/netbeans/show_bug.cgi?id=270091]
> Chinese characters not displayed in table header for ordered column (Windows
> Look&Feel)
> ---------------------------------------------------------------------------------------
>
> Key: NETBEANS-4533
> URL: https://issues.apache.org/jira/browse/NETBEANS-4533
> Project: NetBeans
> Issue Type: Bug
> Components: platform - Outline&TreeTable
> Environment: Windows 7, using the Windows Look and Feel.
> Reporter: Adrien DE GEORGES
> Priority: Major
> Attachments: BugETableChinese.zip, ETableHeader.java.v8.2.patch
>
>
> Scenario:
> * Use the Windows Look and Feel in your Java application (with Metal: no
> problem).
> * Create a ETable with a column header having characters in Chinese or
> Japanese (or any not supported by Tahoma font).
> * When running the program, click on this header to sort the column => these
> characters will be replaced by a square.
> (small Maven project attached, with 1 class and one main method)
> Root cause:
> The headers of the sorted columns will be rendered in bold by the ETable,
> which is done in "ETableHeader::getTableCellRendererComponent". This code
> takes the font of the JLabel used for the rendering, and creates a similar
> font in bold. For that, it does not uses "Font::deriveFont(...)" (because of
> a 2005 bug with Apple's JVM), but uses "(new Font (label.getFont().getName(),
> ...)".
> Under Windows it is a problem:
> * the default font (used here by the JLabel) is a composite font
> * from what I understand, a composite font is a list of physical fonts,
> which will be successively used to try to render a given character.
> * this list of the physical fonts contains one that supports Chinese
> characters.
> * label.getFont().getName() retrieves the name of the first font of the
> composite font, in the case of the Windows Look and Feel it is "Tahoma"
> (which does not support Chinese).
> * so the "new Font(...)" used as a header renderer will be only "Tahoma",
> hence the square characters.
>
> The suggestion is to revert the patch from 2005 as it is not reproductible
> anymore (change of JRE)
> Old code:
> // don't use deriveFont() - see #49973 for details
> label.setFont (new Font (label.getFont ().getName (), Font.BOLD,
> label.getFont ().getSize ()));
> New code:
> label.setFont(label.getFont().deriveFont(Font.BOLD));
> A patch is attached in the ticket.
> Please note that this is a duplicate of a bug already logged in the old
> Bugzilla : [https://bz.apache.org/netbeans/show_bug.cgi?id=270091]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@netbeans.apache.org
For additional commands, e-mail: commits-h...@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
