Under Review
over 1 year ago

Users complain of very small text in simple data fields

Original thread: https://forums.garmin.com/developer/connect-iq/f/discussion/259355/users-complain-of-very-small-text-in-simple-data-fields

Although I can't personally recreate this problem, I am reposting it here for visibility, as multiple users have complained of this issue, for multiple simple data field apps.

Text of original post:


Is this happening to anyone else? At first it was only happening for one of my simple data field apps, so I thought it was an isolated incident.

Now a user of a 2nd simple data field app has made the same complaint. Some users report that they used to see normal-sized text, and one day it suddenly became small. More recently, some new users say that it's always been small.

In one case I'm only displaying characters available in number fonts (for simple data fields *) such as digits, ".", ":", and "-" (verified in the simulator). (* I'm aware that simple data fields may be slightly more restrictive than necessary when it comes to which characters it will display in numerical fonts. i.e. The set of available characters for number fonts may be bigger in some cases than the set of characters that a simple data field will render in a number font). Even in this case, I've asked an affected user to change the settings so that only digits are displayed, and the problem persists.

In the other case I'm only displaying digits.

And I can't recreate this in the simulator or on my real 935 device.

What I see on my watch (normal-sized text):

https://ibb.co/1QC0c5V

What they see on their watch (text that's too small):

https://ibb.co/sFCYvvY

It's not limited to one device as Vivoactive 4 and Edge 530 users have both complained.

The two apps in question are:

https://apps.garmin.com/en-US/apps/fd690281-9c22-4fee-a81e-3b7f39aa67c5

https://apps.garmin.com/en-US/apps/2bc8b0c1-dd83-4679-96f1-0ae2a0925920

The latter (Total Ascent) literally does nothing but convert ActivityInfo.totalAscent to the user's preferred units and round it to a whole number.

using Toybox.WatchUi;

class totalAscentView extends WatchUi.SimpleDataField {

	var elevationUnits;
	function getUnits()
	{
		var settings = System.getDeviceSettings();
		elevationUnits = settings.elevationUnits;
	}

	// m to feet
	private function convertAltitude(value)
	{
		if (value == null)
		{
			return null;
		}
		
		if (elevationUnits == System.UNIT_STATUTE)
		{
			value = value / 0.3048;
		}
		return value;
	}		


    function initialize() {
        SimpleDataField.initialize();
        label = "Ascent";
    }

    function compute(info) {
    	getUnits();
        
        var val = convertAltitude(info.totalAscent);
        if (val == null)
        {
        	return 0;
        }
        
        return Math.round(val).toNumber();
    }
}

  • The funny thing about your test results is that they show that number fonts don't support the space character on Edge devices. IIRC, most or all watches did support spaces in number fonts, at least at one point.

    A very long time ago, Garmin used to publish the supported characters for number fonts in the devices section of the documents. The space character would actually be part of the docs (if supported), but it was impossible to tell if it was there, because the docs would look something like this (with no quotes or other delineation):

    Supported characters for numerical fonts:

    0123456789:-+

    The only way you could tell if space was in there would be to select the text or inspect the HTML source / DOM.

    Another issue (in the past) was that the algorithm used by simple data fields to determine if a string was "purely numerical" (and could be rendered in the number font) would use a subset of the actual characters supported by said number font. So you might have a valid number font character (like space) which would nonetheless cause your string to be rendered with a smaller text font.

    Anyway, all of that is to say there's always been problems with this stuff. But it's pretty annoying to get bad reviews because of something that's beyond my control as a dev. (Obviously I am not going to redesign all my simple data fields to do their own layout/rendering, because I don't enjoy reinventing the wheel, even when I have appropriate code handy in another app. One obvious reason is that, in a perfect world, a CIQ data field shouldn't render itself unless it absolutely has to, since that way the firmware can provide as close to a native look and feel as possible. In a perfect world.)

  • Thanks very much.  Very helpful.  Yes, something like that.  After investigating (in part through your suggestions), I believe there is a bug in the assignment of font size for "Strings" in the large but not small fields in some layouts in the Simple Data Field module/class.  My Simple Data Field app returns a string object that includes some numeric values but also some text characters.  In the smaller fields in some layouts, it is formatted as a string, using a font that is slightly different that the font for used for number objects but roughly the same size.  However, for large fields in some layouts, e.g. 1, 2, some 3, and some 4 field layouts, the string is rendered in a tiny (i.e. really small) font size.  The font style may be the same as for the smaller fields -- it’s too small to see clearly.  The behavior is different in the simulator, where my string object is recognized as a string – as evidenced by the choice of font compared to numeric objects.  In the simulator, the size of the font for string and numeric objects is roughly the same and large enough to nicely fill the field regardless of its size/layout. 

    In the process of the investigation and searching for a work around, I tested the rendering of a series of string objects.  As indicated below, some strings are rendered in the string font, others in the number font.  On my Edge 530, the strings rendered in string font are tiny for the large size fields in some layouts but have sensible size for the smaller size fields.  The size of the strings that are rendered in number font is sensible regardless of the field size across all layouts.  By contrast, there does not seem to be a problem with font size rendering for these strings in the simulator.

    string (formatted as/font used on my Edge 530)

    "--" (number)

    ".." (number)

    “111111” (number)

    "10-11" (number)

    "10-11*" (string)

    "10 - 11" (string)

    "10--11" (number)

    "10 -- 11" (string)

    "10..11" (number)

    "10 .. 11" (string)

    "10_--_11" (string)

    "10_.._11" (string)

    "10^--^11" (string)

    "10^..^11" (string)

    "Test Text" (string)

    "1Test Text" (string)

    "1. Test Text" (string)

    "+Test Text" (string)

    "+1Test Text" (string)

    "+1. Test Text" (string)

    "Test_Text" (string)

    "1Test_Text" (string)

    "1._Test_Text" (string)

    "+Test_Text" (string)

    "+1Test_Text" (string)

    "+1._Test_Text" (string)

  • The text string does not have hyphen/minus/dash symbols that may have triggered smaller font size some years ago

    Yes, but there's additional nuance here, unfortunately. In the past, simple data fields which returned strings would use the larger "numerical" fonts if they only contained numerical characters. Depending on the device, other characters such as hyphen, dash, and blank space would also be considered "numerical characters", for these purposes. One limitation of this behavior was that certain characters which were included in large numerical fonts were apparently not considered "numerical characters" for the purpose of the font selection algorithm. (Fake example: say that for a given device, the large number fonts contained the colon character, but if you returned a string that contained only numbers and the colon character, the simple data field font selection algorithm would use a smaller non-numerical font instead.)

    This behavior seems to have changed in more recent watches so it's only the data type which is considered.

    - If a data field returns a number, the larger numerical font is used

    - If a data field returns a string, the smaller non-numerical font is used, regardless of the contents of the string. (so returning a string with only numerical characters won't result in a larger string.)

    See this comment for anecdotal evidence: https://forums.garmin.com/developer/connect-iq/i/bug-reports/users-complain-of-very-small-text-in-simple-data-fields?CommentId=365ea465-4a3e-4269-9f5f-c3614a4d88ac

    Having said that, your situation may be a different (or may be a combination of issues), since it works differently for different layouts.

    You can validate whether you're seeing the problem that I mentioned above by changing your simple data field app to return a Number, not a String. If it now uses a larger font, then it's the return type issue.

  • Seeing something similar with a Simple Data Field on Edge 530.  The auto scaling of the text/font size seems to work for layouts with 4 or more fields and for the smaller field in layout "3B" (two large, 1 small field). However, for layouts with 1 or 2 fields, or for layout "3A" (3 large and equally sized fields), the text is very small, even smaller than when auto scaled for smaller fields in other layouts.  Fonts look fine in the simulator.  The text string does not have hyphen/minus/dash symbols that may have triggered smaller font size some years ago.  I am aware that a potential fix is to write a Data Field and address font size explicitly, but I hope that effort is not the only solution.

    Any thoughts?   Thanks ...

  • Please Garmin fix this for the Venu SQ.  3rd party data fields (like altitude) are literally unreadable - it's about a 5 or 6 point font:

    If anyone knows a workaround for this, please let me know! I see a reference to the comment below about HMs DIY data field solving the problem, but I don't see any info on what this is or how to get it.