Acknowledged
23 days ago

getFontAscent() doesn't return value in line with standard definition of a fonts ascent

According to the top answer on https://stackoverflow.com/questions/27631736/meaning-of-top-ascent-baseline-descent-bottom-and-leading-in-androids-font, the ascent is the top pixel of standard text. On the Enduro 3 (and others, based on the number of posts about the font ascent/descent on the forums), getFontAscent() returns the value from the Baseline to the "Top" (see diagrams in stackoverflow link), rather than Baseline to Ascent. This is confusing, the api should follow the standard meaning of "ascent", or change the function name to "getFontTop" or something

jerry123
  • 7 days ago

    In your example, the top two lines ("top" and "ascent") are lower than they should be. The '1' character should not go past the "ascent" line. It's an issue for my watchface because I want the move bar to draw the bottom half of the text red when it's 1, the bottom 5/8ths red when it's 2, the bottom 6/8ths red when it's 3, the bottom 7/8ths red when it's 4, and all red when it's 5. But since the ascent value is wrong, it leads to inconsistent steps or sometimes filling the entire time with red at 4 on some watches.

    In my case I vertically center the text, so I should be able to divide the ascent by two and add that to the center Y coordinate of the display, to get the top Y coordinate of the text (for dc.setClip()), and then divide the ascent by 8 to get the steps for each move bar value. But If I do that and set the top of the clipping region to ((ascent/2) + centerY), it cuts off part of the text and the steps for each move bar value are wrong. Setting the clipping region to the top of the ascent shouldn't cut off any text

  • 7 days ago

    Hello,

    I have been trying to look into this and did not find the expected result. I used a test app that uses the getFontAscent() function and displays that value and also the associated lines like in that stack overflow article. I then used a pixel measurer to compare the values and found the expected value. Here are some screenshots of the results both on the actual device and in the simulator




    Probably can't see it very well from just the screenshot without zooming in, but the pixel length from Descent to Ascent is 30, just like the getFontAscent() method returns.

    If you have any specific examples showing an issue I'd be happy to look into it a little further.