looks
  1. looks
  2. LOOKS-182

Default font policy not showing Japanese correctly

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 2.1.4
    • Fix Version/s: 2.6.0
    • Component/s: windows
    • Labels:
      None
    • Environment:

      Operating System: Windows Vista
      Platform: All

    • Issuezilla Id:
      182

      Description

      Serious problem that using the JGoodies LAF the Japanese characters are shown as
      squares, but if you use the Windows (or Suns) Look and Feel the Japanese
      characters are shown. (Swapping from Windows to JGoodies LAF it still continues
      to use the same Tahoma font but stops working)

      Full example below tested on Windows Vista

      import javax.swing.*;

      public class UnicodeTest
      {
      public void start() throws Exception

      { //UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()); UIManager.setLookAndFeel("com.jgoodies.looks.windows.WindowsLookAndFeel"); JTextField txtField = new JTextField(); txtField.setText("\u5742\u672c"); System.out.println("Font is:"+txtField.getFont()); JFrame frame = new JFrame("UnicodeTest"); frame.add(txtField); frame.pack(); frame.setVisible(true); }

      public static void main(String args[]) throws Exception

      { UnicodeTest test = new UnicodeTest(); test.start(); }

      }

        Issue Links

          Activity

          Hide
          karsten added a comment -

          First off, if you report a problem please follow:
          https://looks.dev.java.net/faq.html#howToReportAProblem

          This may be a duplicate of issue #148. Please run the fonttest.jar that ships
          with the Looks distribution in folder /demo. Then please copy the result and
          add it as a comment to this issue.

          What irritates me, is that you talk about Tahoma being used, where Vista's icon
          font should be Segoe UI. Therefore I need the information from the fonttest.jar.

          Show
          karsten added a comment - First off, if you report a problem please follow: https://looks.dev.java.net/faq.html#howToReportAProblem This may be a duplicate of issue #148. Please run the fonttest.jar that ships with the Looks distribution in folder /demo. Then please copy the result and add it as a comment to this issue. What irritates me, is that you talk about Tahoma being used, where Vista's icon font should be Segoe UI. Therefore I need the information from the fonttest.jar.
          Hide
          paultaylor added a comment -

          I ran fonttest.jar (ouput below), win.defaultGUI.font is set to tahamo 11,maybe
          that is the problem. Two other points you say tahoma cant display unicode but it
          appears to be using it with the build in Windows LAF ok. Secondly wrt to issue
          #148 my PC is not configured for Japanese, it is a UK PC, I just happen to be
          viewing Japanese text (and many other languages) in my program.

          Output below:
          Java environment:
          java.vendor=Sun Microsystems Inc.
          java.version=1.6.0_04
          java.runtime.version=1.6.0_04-b12
          java.vm.version=10.0-b19
          sun.desktop=windows

          Operating System:
          os.name=Windows Vista
          os.version=6.0

          Windows Settings:
          Modern Windows=true
          Windows XP=false
          Windows Vista=true
          Windows L&f XP Mode=true

          AWT Properties:
          awt.toolkit=sun.awt.windows.WToolkit
          screen.size=1680 x 1050
          screen.resolution=96 (low)

          User Settings:
          user.language=en
          user.country=GB
          user.timezone=

          Desktop Properties:
          win.defaultGUI.font=Tahoma-plain-11
          win.icon.font=Segoe UI-plain-12
          win.menu.font=Segoe UI-plain-12
          win.messagebox.font=Segoe UI-plain-12
          win.ansiVar.font=Microsoft Sans Serif-plain-11
          win.ansiFixed.font=Monospaced-plain-13
          win.frame.captionFont=Segoe UI-plain-12
          win.tooltip.font=Segoe UI-plain-12

          Internationalization:
          defaultLocale.getDisplayName(Locale.ENGLISH)=English (United Kingdom)
          defaultLocale.getDisplayLanguage(Locale.ENGLISH)=English
          defaultLocale.getDisplayLanguage(defaultLocale)=English
          locale has localized display language=true
          defaultGUI font can display localized text=yes
          icon font can display localized text=yes

          JGoodies Windows L&f:
          controlFont=Segoe UI-plain-12
          menuFont=Segoe UI-plain-12
          titleFont=Segoe UI-plain-12
          messageFont=Segoe UI-plain-12
          smallFont=Segoe UI-plain-12
          windowTitleFont=Segoe UI-plain-12

          JGoodies Plastic L&fs:
          controlFont=Segoe UI-plain-12
          menuFont=Segoe UI-plain-12
          titleFont=Segoe UI-bold-12
          messageFont=Segoe UI-plain-12
          smallFont=Segoe UI-plain-10
          windowTitleFont=Segoe UI-bold-12

          Show
          paultaylor added a comment - I ran fonttest.jar (ouput below), win.defaultGUI.font is set to tahamo 11,maybe that is the problem. Two other points you say tahoma cant display unicode but it appears to be using it with the build in Windows LAF ok. Secondly wrt to issue #148 my PC is not configured for Japanese, it is a UK PC, I just happen to be viewing Japanese text (and many other languages) in my program. Output below: Java environment: java.vendor=Sun Microsystems Inc. java.version=1.6.0_04 java.runtime.version=1.6.0_04-b12 java.vm.version=10.0-b19 sun.desktop=windows Operating System: os.name=Windows Vista os.version=6.0 Windows Settings: Modern Windows=true Windows XP=false Windows Vista=true Windows L&f XP Mode=true AWT Properties: awt.toolkit=sun.awt.windows.WToolkit screen.size=1680 x 1050 screen.resolution=96 (low) User Settings: user.language=en user.country=GB user.timezone= Desktop Properties: win.defaultGUI.font=Tahoma-plain-11 win.icon.font=Segoe UI-plain-12 win.menu.font=Segoe UI-plain-12 win.messagebox.font=Segoe UI-plain-12 win.ansiVar.font=Microsoft Sans Serif-plain-11 win.ansiFixed.font=Monospaced-plain-13 win.frame.captionFont=Segoe UI-plain-12 win.tooltip.font=Segoe UI-plain-12 Internationalization: defaultLocale.getDisplayName(Locale.ENGLISH)=English (United Kingdom) defaultLocale.getDisplayLanguage(Locale.ENGLISH)=English defaultLocale.getDisplayLanguage(defaultLocale)=English locale has localized display language=true defaultGUI font can display localized text=yes icon font can display localized text=yes JGoodies Windows L&f: controlFont=Segoe UI-plain-12 menuFont=Segoe UI-plain-12 titleFont=Segoe UI-plain-12 messageFont=Segoe UI-plain-12 smallFont=Segoe UI-plain-12 windowTitleFont=Segoe UI-plain-12 JGoodies Plastic L&fs: controlFont=Segoe UI-plain-12 menuFont=Segoe UI-plain-12 titleFont=Segoe UI-bold-12 messageFont=Segoe UI-plain-12 smallFont=Segoe UI-plain-10 windowTitleFont=Segoe UI-bold-12
          Hide
          karsten added a comment -

          First, I've changed the summary to a more special case, because in general the
          fonts chosen by the default font policy can display unicode characters. This
          just depends on the glyphs provided by the font.

          The problem seems to be caused by a changing the font, which seems to
          completely remove the font chaining/font fallback mechanism that is used, if
          you don't change fonts at all. And so, the fix for issue #148 should fix this
          problem too. Basically, if desired, you should be able to leave the font setup
          unchanged.

          As a workaround you may set a FontPolicy that returns a font that is capable of
          displaying the characters you want. I'll try to get this fixed for version
          2.2.0 which shall be available by the end of the month.

          Show
          karsten added a comment - First, I've changed the summary to a more special case, because in general the fonts chosen by the default font policy can display unicode characters. This just depends on the glyphs provided by the font. The problem seems to be caused by a changing the font, which seems to completely remove the font chaining/font fallback mechanism that is used, if you don't change fonts at all. And so, the fix for issue #148 should fix this problem too. Basically, if desired, you should be able to leave the font setup unchanged. As a workaround you may set a FontPolicy that returns a font that is capable of displaying the characters you want. I'll try to get this fixed for version 2.2.0 which shall be available by the end of the month.
          Hide
          paultaylor added a comment -

          Hi I dont quite follow you, you say 'the problem seems to be caused by a
          changing the font' but in my example program I dont change the font at all.

          Show
          paultaylor added a comment - Hi I dont quite follow you, you say 'the problem seems to be caused by a changing the font' but in my example program I dont change the font at all.
          Hide
          karsten added a comment -

          The Looks's default font policy changes the font. It aims to use the windows
          icon font for the UI components, because the icon fonts honors the Windows
          platform setting for the font size (Normal/Large/Extra large). Where the Sun
          Windows L&f uses a font that doesn't scale.

          So if you're installing the JGoodies L&fs and use the default font policy,
          it'll change the font (for you).

          Show
          karsten added a comment - The Looks's default font policy changes the font. It aims to use the windows icon font for the UI components, because the icon fonts honors the Windows platform setting for the font size (Normal/Large/Extra large). Where the Sun Windows L&f uses a font that doesn't scale. So if you're installing the JGoodies L&fs and use the default font policy, it'll change the font (for you).
          Hide
          paultaylor added a comment -

          Wondering if any progress on this issue.
          Funnily enough in my actual application I found that some fields exhibited the problem behaviour and some fields did not, even though I was setting the font to Unicode for all of them.

          I also had another go at the workaroud which I failed to understand firsttime round, calling the following line does work, although Im really unsure as to whether this is safe to do on an Windows machines and whether this is best font to use.

          WindowsLookAndFeel.setFontPolicy(FontPolicies.createFixedPolicy(FontSets.createDefaultFontSet(Font.decode("arial unicode MS 12"))));

          Show
          paultaylor added a comment - Wondering if any progress on this issue. Funnily enough in my actual application I found that some fields exhibited the problem behaviour and some fields did not, even though I was setting the font to Unicode for all of them. I also had another go at the workaroud which I failed to understand firsttime round, calling the following line does work, although Im really unsure as to whether this is safe to do on an Windows machines and whether this is best font to use. WindowsLookAndFeel.setFontPolicy(FontPolicies.createFixedPolicy(FontSets.createDefaultFontSet(Font.decode("arial unicode MS 12"))));
          Hide
          golovnin added a comment -

          A possible fix for this issue. It uses so called composite fonts, e.g. it will use Tahoma on WinXP and Segoe UI on Vista/Win7 for western characters and a fall back font for all characters, which are unknown in Tahoma or Segoe UI (incl. japanese/chinese characters). The problem of this solution is that it uses Sun's private API in some situations. So it may not work in a restricted environments, e.g. unsigned applet. Karsten is already knows this solution and investigates whether it is the way to fix this problem.

          This solution has not been tested on Japanese/Chinese native Windows systems. So it may not work on those systems.

          I hope it helps you to fix your problem.

          • Andrej Golovnin
          Show
          golovnin added a comment - A possible fix for this issue. It uses so called composite fonts, e.g. it will use Tahoma on WinXP and Segoe UI on Vista/Win7 for western characters and a fall back font for all characters, which are unknown in Tahoma or Segoe UI (incl. japanese/chinese characters). The problem of this solution is that it uses Sun's private API in some situations. So it may not work in a restricted environments, e.g. unsigned applet. Karsten is already knows this solution and investigates whether it is the way to fix this problem. This solution has not been tested on Japanese/Chinese native Windows systems. So it may not work on those systems. I hope it helps you to fix your problem. Andrej Golovnin
          Hide
          golovnin added a comment -

          I forgot to mention that it only works with Java 6 or Java 7.

          Show
          golovnin added a comment - I forgot to mention that it only works with Java 6 or Java 7.
          Hide
          esigler added a comment -

          The CompositeFontPolicy work around seems to fix the issue for me with the WindowsLookAndFeel, but doesn't seem to fix the issue when used with the PlasticLookAndFeel on WinXP.

          Show
          esigler added a comment - The CompositeFontPolicy work around seems to fix the issue for me with the WindowsLookAndFeel, but doesn't seem to fix the issue when used with the PlasticLookAndFeel on WinXP.
          Hide
          gb2810 added a comment - - edited

          Hi,

          I am pretty sure that I've run into the same issue but I'm left with some open questions...

          I found out that JAVA 7 causes an incompatibility issue with I18N (Hebrew in my case). My applet runs just fine when being used with JAVA 6 JRE or below but when someone has JAVA 7 JRE (which becomes more and more common due to EOL of 6) all the characters are displayed as squares...

          I took the CompositeFontPolicy and set it to the L&F and indeed 90% of the squares were gone and I see Hebrew letters again (except in some titles). However, this caused some other incompatibilities with respect to the font size when displayed in JTable, the line height is no longer sufficient to the chosen font...

          So, here are my questions:
          1 - Am I experiencing the same issue or some other dialect of it ?
          2 - What is it with JAVA 7 that causes the incompatibility ? maybe I should open a defect to Oracle ? maybe they already have a workaround to this problem ?
          3 - if #1 is true==same issue & #2 is false==bug in JGoodies then: this defect is already ~5 years old and is marked as critical (I totally agree with the severity as it prevents users from working with the application since mine is pure Hebrew based and thus....all I see is squares). How come there isn't any stable/robust fix to this matter which doesn't cause other abnormalities and that supports multi-platform etc. ?
          4 - does the paid version of JGoodies (looks) fix this ? if not then I cannot understand how companies can use this 3rd party...

          Thanks.

          Show
          gb2810 added a comment - - edited Hi, I am pretty sure that I've run into the same issue but I'm left with some open questions... I found out that JAVA 7 causes an incompatibility issue with I18N (Hebrew in my case). My applet runs just fine when being used with JAVA 6 JRE or below but when someone has JAVA 7 JRE (which becomes more and more common due to EOL of 6) all the characters are displayed as squares... I took the CompositeFontPolicy and set it to the L&F and indeed 90% of the squares were gone and I see Hebrew letters again (except in some titles). However, this caused some other incompatibilities with respect to the font size when displayed in JTable, the line height is no longer sufficient to the chosen font... So, here are my questions: 1 - Am I experiencing the same issue or some other dialect of it ? 2 - What is it with JAVA 7 that causes the incompatibility ? maybe I should open a defect to Oracle ? maybe they already have a workaround to this problem ? 3 - if #1 is true==same issue & #2 is false==bug in JGoodies then: this defect is already ~5 years old and is marked as critical (I totally agree with the severity as it prevents users from working with the application since mine is pure Hebrew based and thus....all I see is squares). How come there isn't any stable/robust fix to this matter which doesn't cause other abnormalities and that supports multi-platform etc. ? 4 - does the paid version of JGoodies (looks) fix this ? if not then I cannot understand how companies can use this 3rd party... Thanks.
          Hide
          guille.rodriguez added a comment - - edited

          I can confirm this problem is also present in JGoodies Looks 2.5.3. In my setup, an application using com.jgoodies.looks.windows.WindowsLookAndFeel with default fonts cannot display Chinese characters whereas all is OK if I switch to the standard L&F (as returned by UIManager.getSystemLookAndFeelClassName()). I am using Windows XP and my default locale is Spanish.

          I can also confirm that using Andrej Golovnin's CompositeFontPolicy fixes the problem for me.

          Show
          guille.rodriguez added a comment - - edited I can confirm this problem is also present in JGoodies Looks 2.5.3. In my setup, an application using com.jgoodies.looks.windows.WindowsLookAndFeel with default fonts cannot display Chinese characters whereas all is OK if I switch to the standard L&F (as returned by UIManager.getSystemLookAndFeelClassName()). I am using Windows XP and my default locale is Spanish. I can also confirm that using Andrej Golovnin's CompositeFontPolicy fixes the problem for me.
          Hide
          karsten added a comment -

          The Windows font lookup and the font policies have been overhauled and now aim to build composite fonts so they use the same glyph fallback mechanism as the core Swing L&fs.

          Show
          karsten added a comment - The Windows font lookup and the font policies have been overhauled and now aim to build composite fonts so they use the same glyph fallback mechanism as the core Swing L&fs.

            People

            • Assignee:
              karsten
              Reporter:
              paultaylor
            • Votes:
              2 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: