Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Works as designed
    • Affects Version/s: current
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Hi,

      I came across a bug while using thorsten android porting of lwuit (i know its officially supported but this bug is a general bug which just manifested itself in the android port)

      i found this bug after HOURS of searching why all my text in android was reverse (hebrew) and not like the bb,midp ports
      i looked at the bidi and tracked line by line of code untill i finally found that it doesnt call CustomFont for the text drawing (i use bitmap fonts) (the matter of why the underlying system font not support hebrew for rtl visual ordering is not part of this bug ofcourse)

      i found that since the androind port return true for isCreationByStringSupported() which cause the variable font to have a none null value, the code below seems like it SHOULD handle it and if indeed bitmap font exists it will use it because it comes after the lookup part HOWEVER loadBitmapFont which font is being passed as an argument checks if it is null and only then loads bitmap font otherwise font (the argument) is return.

      under Resources::loadFont method
      the following code
      boolean lookupIncluded = input.readBoolean();
      if(lookupIncluded) {
      String lookup = input.readUTF();
      if(font == null && Font.isCreationByStringSupported())

      { font = Font.create(lookup); }

      }
      boolean bitmapIncluded = input.readBoolean();
      if(bitmapIncluded)

      { font = loadBitmapFont(input, id, font); }

        Activity

        Hide
        vprise added a comment -

        This is intentional since lookup fonts should take priority over bitmap fonts which is especially important in platforms such as Android. However, it makes sense to ask the implementation for an API to disable lookup fonts at least until we can get our loadable fonts act together (we need to support TTF loadable fonts).
        Regarding Hebrew in Android, works great on properly localized hardware (e.g. Galaxy S) doesn't work properly with default Google devices (e.g. Nexus One). You can workaround that device bug by using this code in the AndroidImplementation:
        @Override
        public void drawString(Object graphics, String str, int x, int y)

        { // Uncomment this if you need to run on a device that doesn't have proper bidi support // like some hacked 3rd party devices, unfortunately I can't find a way to detect // this situation on the fly //str = Display.getInstance().convertBidiLogicalToVisual(str); ((AndroidGraphics) graphics).getCanvas().drawText(str, x, y - ((AndroidGraphics) graphics).getFont().getFontMetricsInt().ascent, ((AndroidGraphics) graphics).getFont()); }

        Problem is that you can't "detect" whether a device is broken or not.

        Show
        vprise added a comment - This is intentional since lookup fonts should take priority over bitmap fonts which is especially important in platforms such as Android. However, it makes sense to ask the implementation for an API to disable lookup fonts at least until we can get our loadable fonts act together (we need to support TTF loadable fonts). Regarding Hebrew in Android, works great on properly localized hardware (e.g. Galaxy S) doesn't work properly with default Google devices (e.g. Nexus One). You can workaround that device bug by using this code in the AndroidImplementation: @Override public void drawString(Object graphics, String str, int x, int y) { // Uncomment this if you need to run on a device that doesn't have proper bidi support // like some hacked 3rd party devices, unfortunately I can't find a way to detect // this situation on the fly //str = Display.getInstance().convertBidiLogicalToVisual(str); ((AndroidGraphics) graphics).getCanvas().drawText(str, x, y - ((AndroidGraphics) graphics).getFont().getFontMetricsInt().ascent, ((AndroidGraphics) graphics).getFont()); } Problem is that you can't "detect" whether a device is broken or not.
        Hide
        vprise added a comment -

        Incorrectly resolved as fixed, resolved as works as designed instead

        Show
        vprise added a comment - Incorrectly resolved as fixed, resolved as works as designed instead
        Hide
        tempusername added a comment -

        i think bitmap font should take priority over lookup fonts because its what the developer/designer defined in the theme you cant change it at run time with out notifying the developer/designer in someway.
        also i think if bitmap fonts were defined then they were defined for a reason.
        i do agree that lookup fonts should take priority over system fonts (for sure).

        Show
        tempusername added a comment - i think bitmap font should take priority over lookup fonts because its what the developer/designer defined in the theme you cant change it at run time with out notifying the developer/designer in someway. also i think if bitmap fonts were defined then they were defined for a reason. i do agree that lookup fonts should take priority over system fonts (for sure).
        Hide
        vprise added a comment -

        Since a platform that supports a lookup font has pretty elaborate fonts, using bitmap fonts on that platform is usually not a good idea. Bitmap fonts are a patch specific for J2ME where we cannot load proper fonts.

        We won't change this in LWUIT but implementations can provide such an API if they desire. I would consider the usage of a bitmap font on a device like Android to be a design bug. Sub pixel anti-aliasing cannot possibly be addressed properly by bitmap fonts which have no knowledge of RGB pixel layout within a specific device or the orientation constraints.

        Show
        vprise added a comment - Since a platform that supports a lookup font has pretty elaborate fonts, using bitmap fonts on that platform is usually not a good idea. Bitmap fonts are a patch specific for J2ME where we cannot load proper fonts. We won't change this in LWUIT but implementations can provide such an API if they desire. I would consider the usage of a bitmap font on a device like Android to be a design bug. Sub pixel anti-aliasing cannot possibly be addressed properly by bitmap fonts which have no knowledge of RGB pixel layout within a specific device or the orientation constraints.
        Hide
        tempusername added a comment -

        i know that lookup fonts/ native fonts work much better & faster than bitmap fonts but then you have the chance of missing support for language X on the handset which can ruin your app and sometimes the look itself isnt the same as the font you've chose in the designer which can cause your app look to stray a bit from the design (cut off texts etc).
        Maybe a method should be added something like allowOverrideBitmapFont which will set a flag to true/false

        Show
        tempusername added a comment - i know that lookup fonts/ native fonts work much better & faster than bitmap fonts but then you have the chance of missing support for language X on the handset which can ruin your app and sometimes the look itself isnt the same as the font you've chose in the designer which can cause your app look to stray a bit from the design (cut off texts etc). Maybe a method should be added something like allowOverrideBitmapFont which will set a flag to true/false
        Hide
        vprise added a comment -

        That flag should be added in the implementation if at all.
        I18n for devices that support lookup fonts but don't support the language will be impractical. You might be thinking about something like using the LWUIT VKB on Android but this will give such a low quality experience in comparison to the proper native VKB that it won't be practical.
        If your application doesn't look the same due to a font I suggest you fix your code/theme to work properly with the 9-patch border and related strategies to multi-resolutions. Devices that support lookup fonts such as Android devices have remarkably high DPI ratios and supporting that range with bitmap fonts would require many different versions of your application. Not a practical long term strategy even for large companies.

        Show
        vprise added a comment - That flag should be added in the implementation if at all. I18n for devices that support lookup fonts but don't support the language will be impractical. You might be thinking about something like using the LWUIT VKB on Android but this will give such a low quality experience in comparison to the proper native VKB that it won't be practical. If your application doesn't look the same due to a font I suggest you fix your code/theme to work properly with the 9-patch border and related strategies to multi-resolutions. Devices that support lookup fonts such as Android devices have remarkably high DPI ratios and supporting that range with bitmap fonts would require many different versions of your application. Not a practical long term strategy even for large companies.

          People

          • Assignee:
            Unassigned
            Reporter:
            tempusername
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: