Font size reduced in simple data field when returned a char

Former Member
Former Member
I'm developing a simple data field and I'm using the following code for returning my compued value as string on the screen:
return (outvar*100).format("%.0f").toString() + "%"


I have observed that concatenating "%" to (outvar*100).format("%.0f").toString() brings to a smaller font of the output.
Further in the simulator the font size is fine, only on my edge 520 the return value font is reduced a lot.
Is it possible to manage the font size in a simple data field?

Are there alternative approaches?
  • I think you're running into the same problem as I reported here. I'm going to complain again as I really feel that this is a bug. The negative sign and percent symbol are both in all of the number fonts used by all devices.

    Currently your only option is to stop using SimpleDataField and draw the number string yourself.
  • i dont have access to the bug report. is there any news about it?
  • It appears that post was moved. Here is the test case that I provided...

    using Toybox.Application as App;
    using Toybox.WatchUi as Ui;

    class ZZZView extends Ui.SimpleDataField
    {
    hidden var _M_method = 0;

    hidden var _M_methods = [
    :returnNumber,
    :returnNegativeNumber,
    :returnNegativeNumberString,
    :returnFloat,
    :returnNegativeFloat,
    :returnNegativeFloatString,
    :returnPercent
    ];

    function initialize() {
    SimpleDataField.initialize();
    }


    function compute(info) {
    var callback = method(_M_methods[ _M_method % _M_methods.size() ]);
    ++_M_method;
    return callback.invoke();
    }

    function returnNumber() {
    return 1; // draws using a number font
    }

    function returnNegativeNumber() {
    return -1; // draws using a number font
    }

    function returnNegativeNumberString() {
    return (-1).format("%d"); // draws using a non-number font, but why should it?
    }

    function returnFloat() {
    return 2.0; // draws using a number font
    }

    function returnNegativeFloat() {
    return -2.0; // draws using a number font
    }

    function returnNegativeFloatString() {
    return (-2.0).format("%.2f"); // draws using a non-number font, but why should it?
    }

    function returnPercent() {
    return 3 + "%"; // draws using non-number font, but why should it?
    }

    }

    class ZZZApp extends App.AppBase
    {
    function initialize() {
    AppBase.initialize();
    }

    function getInitialView() {
    return [ new ZZZView() ];
    }
    }


    The response I got indicated that the SimpleDataField examines the string returned from compute(), and if it contains only characters in 0123456789:., the string will be drawn with a numeric font. I requested that +-% be added to the list as those symbols frequently are used to represent numeric content.

    I don't believe there has been any action on this, but if you think it should be changed, it might be worth reporting it again by posting to the Bug Reports forum.

    Travis
  • The response I got indicated that the SimpleDataField examines the string returned from compute(), and if it contains only characters in 0123456789:., the string will be drawn with a numeric font.
    That seems to be an accurate description of the implementation, and I agree that is some strange logic.

    Is the intent to only use a number font if the every character in the string is available in the font? That would make sense, but we know from the documentation that the minus sign and the percent symbol are present (but the plus sign and the degree symbol are not) in every number font on every device model, even if the design intent was to further constrain it to the minimum common character set, and that logic would not preclude displaying the strings “-2.6” or “94%” using a number font. It's obvious that the implementation does not follow that logic.

    Is the intent to only use a number font if the string represents a valid scalar value? If so, “-2” represents a valid scalar value while “3..1:2.:” doesn't, but the former is somehow refused for display using a number font while the latter is not. It's obvious that the implementation does not follow that logic, either.
  • It is my understanding that information about what characters are in the font are not available at runtime. The set of characters allowed is predetermined, is a subset of the characters in the numeric fonts for all devices, and I don't believe is subject to change.

    I agree with you though. I've brought this one up twice and it hasn't got the attention that I would have hoped. Considering the complexity of the work around (implementing a full-fledged DataField) and the apparent simplicity of the fix, the solution seems obvious. That said, I'm not privy to all of the facts and I could be completely off base.

    Travis
  • Hi Travis, thanks as always. IMHO this is a bug. it makes no sense that a larger font is used for positive numbers than for negative ones. I dont expect any action though. I am having bad luck with my reported issues...
  • it makes no sense that a larger font is used for positive numbers than for negative ones.
    To be fair, the same (number) font is used whether I put:
    • [FONT=Courier New]return 2;
    • [/FONT]
    or
    • [FONT=Courier New]return -2;
    • [/FONT]
    or
    • [FONT=Courier New]return "-2".toNumber();
    • [/FONT]

    in my code for the compute() method.

    Besides, don't they say size doesn't matter? :p
  • Hi,

    I've done a far bit of research into this, as I' have a number of Simple Data Fields. Basically, I've found it is device dependant is related to what characters are available in the FONT_NUMBER_* fonts (which varies by device)

    Therefore, if you think what Characters are used in a Watch Face (where larger numbers are typically displayed) then these are then chosen for larger areas on Simple Data Fields. These are typically characters 0-9 and colon. I did find minus and percent were missing (and even plus), and also lots of brackets and underscores etc.

    It's a real minefield, as I had users complaining about the font resizing when having numbers below zero and the minus was required. Also, I've had some users reporting the Font used, even when the same size, being different to native fields (https://forums.garmin.com/showthread.php?360088-Minor-Simple-Data-Field-not-using-same-font-as-Native-Fields).

    Cheers
    Chris