FWD » Core Development » Base Language

Package the changes as a proper update zip. These do not affect anything in the conversion or runtime, so we will just apply them to staging and check them into Bazaar without further testing.

After that, please examine the com/goldencode/p2j/ui/client/swing/SwingHelper class. In there you will find isMonospaced() and getMonoFontList(). I suspect the problem is in our test for whether something is a monospaced font. Please debug through there and see if you can identify the root cause of the font problem.

The only change needed is to re-zip the update without the p2j/ prefix. Zip everything from inside the p2j/ directory and it will be good to go.

Attach that final zip to this task. Then you can check it in and apply it to staging.

To clarify on the directory changes needed: it seems that the required changes are in the file-system section (propath, file-separator, path-separator).

Applied to staging and checked in Bazaar.

More investigation.

Looks like the reason for screen corruption in Windows monospaced has been found. The CHUI output is a combination of two types of chars: one - letters and " " and another - so called "Box Drawing" chars(frame border chars starting with \u2500). And on the other hand the Java logical font can be composite meaning one logical font can be mapped to the several physical ones to cover the full Unicode range if single physical font can not render all required characters. In our case the "Box Drawing" characters are really wider than basic Latin charset(0x00 - 0x7F).

So we need monospaced font is able to draw the both letters and frame border chars simultaneously. In this case all required characters will have the same size. I would offer to use the helper function like below before first usage of the ChUI client:
Class SwingHelper:
public static synchronized String getMonoFont(Component comp, String defaultFont) {
String[] all = getMonoFontList(comp);
for (int i = 0; i < all.length; i++) {
Font font = Font.decode(all[i]);
if(font.canDisplay('\u2500')) {
FontMetrics fm = comp.getFontMetrics(font);
if(fm.charWidth('i') == fm.charWidth('\u2500'))
return all[i];
}
}
return defaultFont;
}
The method returns unchanged font name if we can not find required font and this is the last resort to trust the Java logical font selection. Yes, we will use here the physical font but it is platform neutral. For every OS the choice will be different. It is tested in both Windows and Linux and works fine. In my Windows it selects real "Courier New". In my Linux box it selects DejaVu Sans Mono. What do you think about this solution?

OK, this is close. But it seems that the real problem is just with our isMonospaced() implementation. In other words, you have found some flaws with our testing of a font to see if it is really monospaced. So, let's change the getMonoFontList() to go from this:

            Font font = Font.decode(all[i]); 

            if (isMonospaced(comp.getFontMetrics(font)))
            {
               array.add(all[i]);
            }

to this:

            Font font = Font.decode(all[i]); 

            if (isMonospaced(font, comp.getFontMetrics(font)))
            {
               array.add(all[i]);
            }

Then change isMonospaced() to this:

   public static boolean isMonospaced(Font font, FontMetrics fm)
   {
      if (!font.canDisplay('\u2500'))
         return false;

      // check if this font is monospaced, this is a bit of a hack but should
      // be reliable
      int msize = fm.charWidth('m');
      int isize = fm.charWidth('i');
      int osize = fm.charWidth('1');
      int nsize = fm.charWidth('9');
      int dsize = fm.charWidth('\u2500');

      return (msize == isize && msize == nsize && msize == osize && osize == dsize);
   }

Please review and confirm that it has the same result as your approach. The idea is to exclude any invalid fonts from the master list. Then anything from that list can be chosen safely.

Your change is not enough to get the ChUI client working. Consider the constructor of the ChuiSimulator class. The getMonoFontList() is not called in the first displaying of the client. It calls configure(options) which in turns does:

...
         if (!SwingHelper.isMonospaced(font, fm))
         {
            throw new IllegalArgumentException("Font face '" + 
                                               options.fontname +
                                               "' must be fixed width.");
         }
...

   public ChuiSimulator(Frame           frame,
                        ContainerOps    container,
                        TerminalOptions options)
   {
      configure(options);

...

   public ChuiSimulator(Frame           frame,
                        ContainerOps    container,
                        TerminalOptions options)
   {
      if(options.fontname.equalsIgnoreCase("monospaced"))
         options.fontname = SwingHelper.getMonoFontList(this)[0];
      configure(options);
...

   public ChuiSimulator(Frame           frame,
                        ContainerOps    container,
                        TerminalOptions options)
   {
      if(options.fontname.equalsIgnoreCase("monospaced"))
         options.fontname = SwingHelper.getMonoFont(this, options.fontname);
      configure(options);
...

   public static synchronized String getMonoFont(Component comp, String defaultFont)
   {
      String[] all = getMonoFontList(comp);
      if(all.length > 0)
         return all[0];
      else
         return defaultFont;
   }

Go with your 2nd approach:

   public ChuiSimulator(Frame           frame,
                        ContainerOps    container,
                        TerminalOptions options)
   {
      if(options.fontname.equalsIgnoreCase("monospaced"))
         options.fontname = SwingHelper.getMonoFont(this, options.fontname);
      configure(options);
...

Except, rename getMonoFont() to getMonoFontName() which is more descriptive.

OK. What about changes testing and uploading?

The code involved in the change does not affect the usual client behavior and regression tests. Do we need to run harness for this change anyway?

Should I commit this change to the P2J bzr project? Or for now we hold this change for future releases?

Prepare the update zip file and attach it to this issue's history. I will then do a final code review and let you know.

You can check in the change to bzr and apply it to staging.

Checked in p2j bzr and applied to staging.

Need to run ant jar in staging p2j to take effect.

I rebuilt staging. Please distribute the update via email.

I am removing the directory example because it contains some confidential information. The portion that was important is this (in the /server/standard/runtime/ section):

          <node class="container" name="default">
            <node class="container" name="file-system">
              <node class="string" name="pkgroot">
                <node-attribute name="value" value="com.goldencode.testcases"/>
              </node>
              <node class="string" name="propath">
                <node-attribute name="value" value=".;"/>
              </node>
              <node class="string" name="path-separator">
                <node-attribute name="value" value=";"/>
              </node>
              <node class="string" name="file-separator">
                <node-attribute name="value" value="\"/>
              </node>
              <node class="boolean" name="case-sensitive">
                <node-attribute name="value" value="TRUE"/>
              </node>
            </node>
          </node>