But on the font height, what you see is correct. The characters in that font might not use the fill height. These are fonts native to the FW, and the white space could be how they do spacing, as the don't want the bottom of line 1 to be right next to the top of line2.If there was no whitespace at all, doing things like y+=fontHeight wouldn't work well for spacing if you consider that.
jim_m_58 agreed. But for certain use cases, either users or devs want larger fonts in a certain area (e.g. when the app draws a 4 or 6 field layout). In that case it can be useful to ignore or hardcode the font height for certain devices.
I wrote a 6-field app where I respected all the font heights, which produced fonts which looked too small to some users. (Font sizing was dynamic, based on the width and height of content.) They said “can I have larger fonts on my 235?” So I ignored the font height for devices that had a lot of white space.
We can see just from the 3 examples that VA3 and F3 obviously have a lot more whitespace than F5.
And when you are using medium, large or extra large numerical fonts, the whitespace difference can be pretty dramatic. I believe some ppl use custom fonts for VA3 to get around this very issue. So I’m suggesting an alternative that may be a lot uglier code-wise, but would save a lot of memory over custom fonts. Although for most cases, it would be better to just respect the font height.
Another example is a lap history data field I wrote which displays lap info in rows. For 935, I could fit a certain number of rows on the screen using small fonts, but for VA3 I could fit fewer rows, because of the whitespace, even though the physical size of fonts seemed similar if you ignored whitespace. So I cheated and hardcoded certain things so I could get similar results on the different platforms.
I get that the stuff with whitespace is intentional and is supposed to make things look nicer. So I don’t recommend doing hacks like I described unless users complain or if you feel like your apps are too different across platforms.
The fonts on the device won't change, and therefore, the FONT_* and FONT_NUMBER_* fonts won't change. For this to occur, all the native screens on a watch would have to change. It won't happen.
But there are ways to handle things that aren't really expensive. For example, I mentioned using VCENTER to position fonts. You can also do simple things like
if(fontHeight==xyz) {fontHeight-=10;}
A small adjust to a given font height, which can be based on things like shape, width and height if need be.
Or, you can use layouts....
I have 30+ apps that use FONT_NUMBER_* fonts that run on about any target. It's just a matter of having a few tricks.
jim_m_58 right I never suggested the fonts on the devices would change. I only pointed out that the same code produces different looking results in a different devices, as we all know. In cases where data is dynamic, you may fit different amounts of data on VA3 versus 645, even if you use the “same” fonts, due to the whitespace/height difference.
Yes, your example of manually adjusting the font height is similar to what I mentioned about hardcoding font height/vertical offset for some devices. In some apps, I hardcode the font height for VA3, F3, Approach S60, 235 and any other devices where I feel there’s “too much” whitespace.
To be fair, my apps don’t look amazing or anything, so I wouldn’t copy my example unless you feel it’s necessary. I’m sure the best practice for attractive-looking apps would be to respect the font height.
Edit: I checked and font height is already defined as ascent vs descent so I’m not sure if it makes sense to add ascent to height in any case. I guess the only solution to make things look good on all devices to add either add or subtract whitespace manually, where you feel it’s necessary, or to calculate padding (or align vertically centred) based on available vertical space.
Small tweaks are needed at times. That's a nice thing about the fonts being constant on each device. New FW won't break those tweaks.
There was at one time thought of having consistent (or more consistent) fonts across different devices. That's where the FONT_SYSTEM_* things came from, but it never happened.
Yep. I can’t speak for anyone else, but all my apps that have any non-trivial draw calls have device-specific tweaks. This goes back to why it’s necessary to test on all device families.
I originally tried writing generic code, but it just didn’t look good / consistent on every device and/or users mentioned they wanted bigger fonts.
I think the worst case of device specific behaviour is the proportional-width numbers in some fonts for F3 and VA. If you horizontally center numbers (in a certain region of the screen) based on width and they change rapidly, they will look like they are “dancing” back and forth. Same goes if you calculate a dynamic column layout based on the max width of column contents. This is less of a problem on devices that have all fixed-width numbers.
I realize there’s many ways around this, but it’s another example of device-specific differences to watch out for.
