Using digits as goal binded progress bar

What are you after? 

beva said:

correct date for the height

date?

data

flocsy🤠 said:

date?

I think they mean "data".

flocsy🤠 said:

What are you after? 

I think they want the "real" height of digits in a numeric font (i.e. height excluding any vertical whitespace), so they can vertically fill the digits like a progress bar, as in the photo

Do Dc.getFontAscent, getFontDescent, getFontHeight together help?

flocsy🤠 said:

Do Dc.getFontAscent, getFontDescent, getFontHeight together help?

Isn't it well-known that these functions don't give you the true height of fonts in all circumstances [*], and haven't you been part of some of these discussions???

[*] (the very existence of a 3rd-party function called getApproxNumberFontHeightInPixels should also be a clue)

https://forums.garmin.com/developer/connect-iq/f/discussion/325515/is-there-a-way-to-look-into-the-fonts

In this thread (which you started) there's a discussion about getting relevant font data from the sim files using @markw65/monkeyc-optimizer, which includes the "internalLeading" value (which is notably not available from the API):

markw65 said:

flocsy said:

Also do you know what does internalLeading mean

Sort of. It's basically the space above the characters reserved for diacritical marks. The problem is that that isn't well defined, so it's whatever the font designer decides it is. But yes, generally, for numbers, or "ordinary" letters, it's likely to be empty space above the actual characters (and to the extent that I've tested it, thats exactly what I found with the Garmin fonts).

But even then, you concluded that all of this data is not sufficient to create pixel perfect apps, because the fonts in the sim are not necessarily the same as the fonts in the devices.

flocsy🤠 said:

So the only feasable way to create an app that looks the way you like is to use custom fonts, because that'll almost look like on the real device.

https://forums.garmin.com/developer/connect-iq/i/bug-reports/getfontascent-doesn-t-return-value-in-line-with-standard-definition-of-a-fonts-ascent

Also, the getApproxNumberFontHeightInPixels function OP mentioned looks at getFontAscent, getFontDescent, and getFontHeight, but also has some hardcoded adjustments for various part numbers. Based on what they said, I guess it's not enough.

I mean, it is called "Approx...Height". And if it relies on hardcoded adjustments based on part numbers, I don't see how it can stay current unless it's constantly updated when new devices come out. (Similar to how the other approach looks at the sim device files themselves.)

https://forums.garmin.com/developer/connect-iq/f/discussion/318635/function-returning-approx-true-height-for-build-in-number-fonts

That's why I was asking if those 3 functions work for what he needs. The above threads are more general and try to do something different. Here he only needs the correct values for the digits, so that might work. It also depends on the font that is being used.

This has come up many times over the years due to the various white space sizes, and while you can add logic to understand the differences, the simplest solution is to use custom fonts where all 240x240 devices use the same font, and all 360x360 use the same, etc.  You can also use the exact size that looks best and aren't limited to the sizes of the native fonts and aren't stuck with just the MEDIUM, HOT, THAI_HOT, etc.

It's what I've done with watch faces for years.

Sadly it does not work. And using workarounds might give problems if it would be corrected in a future update. I'll choose another route that also allows more creativity.