Fenix3 Simulator Width Calculations Wrong

EDIT: I wrote Fenix3 in the subject, I meant Forerunner 920XT. Oops.


I have some word-wrapping code that is working under the simulator for all devices except the Forerunner 920xt.

I traced the issue back to a core problem that affects the Forerunner only:

The sum of the width of each character in a string is not equal to the width of the whole string.


Here's a bit of test code and the results across devices:

var testString = "When in the course of h";
System.println("width of whole string=" + dc.getTextWidthInPixels(testString, Gfx.FONT_MEDIUM));
var sumOfCharWidths = 0;
var curChar, curCharWidth;
for (var i=0; i < testString.length(); i++) {
curChar = testString.substring(i, i + 1);
curCharWidth = dc.getTextWidthInPixels(curChar, Gfx.FONT_MEDIUM);
sumOfCharWidths += curCharWidth;
}
System.println("width of sum of chars=" + sumOfCharWidths);



FONT_MEDIUM
- fr920xt
width of whole string=199
width of sum of chars=177

- epix
width of whole string=205
width of sum of chars=205

- vivoactive
width of whole string=205
width of sum of chars=205

- fenix3
width of whole string=221
width of sum of chars=221

I'm curious if this is just a simulator bug or whether this affects the device as well.

Thanks!
  • Is it wrong on the simulator or also wrong on the device? If it's only in the simulator, post on the "Simulator bugs" thread... The simulator has a few issues with fonts....

    This is one of the reasons you should be careful about claiming support for a device unless you know it's been run on the real device, and not just the simulator.... (that's why a "beta" area need to be added to the app store for CIQ, so stuff can be tested on real devices developers don't have)
  • Is it wrong on the simulator or also wrong on the device? If it's only in the simulator, post on the "Simulator bugs" thread... The simulator has a few issues with fonts....


    I don't own an Forerunner so no idea if it's affects the actual device, but if someone out there with a Forerunner wants to try that test code and report back I'd be eternally grateful.

    I'll go ahead and cross-post this to the Simulator bugs thread.
  • In the mean time, don't have a 920 version in the app store, as it might give both CIQ and the device a bad name to users!
  • In the mean time, don't have a 920 version in the app store, as it might give both CIQ and the device a bad name to users!


    I don't know about that. This is a relatively minor page-rendering bug, the app is still useful even if this bug affects the device. I'd rather just ship it, and if anyone notices an issue, I'll be happy to fix it ASAP.

    From what I've seen, the devices themselves tend to be a lot saner than the simulator, so more than likely this is just a simulator bug.
  • Former Member
    Former Member over 10 years ago
    So, first of all, this is just not something you can do. Second, I am straight up baffled that the values match on Epix, VivoActive, and Fenix 3. What you are seeing on the 920XT is the expected outcome, and not getting different results on the others might mean there is an issue on those devices.

    Why can't you do this? Because counting each character individually doesn't account for the space (or lack of space) between characters (kerning). When you get text extents for a string, you will get the number of pixels from the front edge of the first character to the back edge of the last character. The width of your string is going to vary based on the font being used, and the order of characters.

    The sum of a strings characters is not going to equal the width of the string except by coincidence.

    |AFV|
    |FAV|
  • I didn't think that ConnectIQ supported proper kerning and simply took the character data from the font file and blitted the data to the screen. Given my understanding of how it has been described and your AFV vs FAV example above, it appears that there is no kerning support and that rconradharris is correct.

    Additionally, if it were kerning that was the issue here, I'd expect the sum of the widths of each character to be greater than the width of the string (A and F may each be 20 pixels wide, so the sum of widths would be 40, but when they are adjacent in a string they should overlap slightly giving some width less than 40). Unless of course the kearning values were backwards and added space where none was needed.
  • Former Member
    Former Member over 10 years ago
    The 920XT does not use kerning pairs, but it does have spaces between the characters. Those will not be counted if you add up the width of each character individually. I believe the other devices do have kerning in their native fonts.

    The AFV example was just an example to demonstrate that the width of a string is not equal to the width of each of its characters individually. The example doesn't really apply to what is being seen here on the 920XT, so it probably wasn't the best for this situation.

    Regardless, text extents should be giving you the exact measurement from the leftmost active pixel in a string to the right most active pixel in a string. This is not the same as the sum of the text extents of each character.
  • Former Member
    Former Member over 10 years ago
    I didn't think that ConnectIQ supported proper kerning and simply took the character data from the font file and blitted the data to the screen.


    Just to clarify things, this is correct for custom fonts. The resource compiler is not using the kerning value from the generated font file. Native font may support kerning (Brian could probably address that better than myself).