Complete
over 6 years ago

WERETECH-7191

Custom, subsetted weather icon font rendering incorrectly on real 735XT

Dear Connect IQ Team,

Two users, both on Forerunner 735XT, have reported that weather symbols are appearing as rectangles, on the Crystal watch face (https://github.com/warmsound/crystal-face). This issue has only been reported on that watch model, and I'm unable to reproduce the issue on the simulator. The latest report was a user running the latest 9.40 firmware for 735XT.

I'm using the Weather Icons font (https://erikflowers.github.io/weather-icons/). I've created a single custom font using the BMFont tool, containing only the code points that I need. The code points are around the 0xf0XX value e.g. 0xf00d for daytime/sunny.

In order to save runtime memory, I've created two subsetted fonts from this single .fnt file, WeatherIconsFontDay, and WeatherIconsFontNight. For the filter attribute of the <font> definition, I've inserted what I believe to be the correct characters corresponding to the code points that I need for day, and for night. I actually generated these characters using JavaScript e.g. String.fromCharCode(61453, 61452, 61442, ...). The filter string appears as rectangles within my code editor, but appears to work correctly on most watches, and in the simulator (code).

At risk of getting my wrists slapped :), I dynamically load the appropriate weather font at draw time, but only when the weather forecast changes from day to night, or vice versa (code).

I thought I'd report this in case there's a genuine bug somewhere in the resource compiler, but I'm also happy to be told that I should be doing things a more sensible way e.g. creating two separate .fnt files, one for day, one for night, to avoid the need for the unreadable filter string! If there's anything else I'm doing that might be causing this issue, I'd be happy to try and fix it.

Many thanks,

Vince.

warmsound
  • over 6 years ago

    While this may be a bug (I haven't really looked into it), but I'm with Jim. I'd use regular ASCII characters.

  • over 6 years ago in reply to jim_m_58

    Are you using weather:icon in the response for this?  I've used OWM in a bunch of stuff, but just use weather:main for the text version.  I can't find a list of the weather:icon values in the API, to see if there might be a good way to map them without using a 64 bit "character".

    Is it something like 

    "04n"
    means icon4 - night?
  • over 6 years ago

    Is is that all the icons show as boxes on the 735?  In that case, I'd look at how you're doing the character to font mapping, as what you're doing means 64bits for the character which could confuse some devices.

    I'd switch to something that wouldn't require that.  say use "a" to "z" for day, and "A" to "Z" for night.  That way a toUpper() could be used to convert day into night.

  • over 6 years ago in reply to jim_m_58

    My user has just supplied a .fit file containing a short recording from his location (.zip attached). I've run this through the simulator on the 735XT, fully expecting to reproduce the problem, but the icon actually appears correctly (light rain showers at night, weather code "09n", which my code should handle correctly - see screenshot). My user says the icon has never appeared correctly for him.

    So we may still be looking at a problem that's specific to the real 735XT device, but it's tricky for me to confirm this.

    3618933196.zip

  • over 6 years ago in reply to warmsound

    Oops, that's what the "Enter to Reply" settings does...

    Thanks for your advice on this - you're right that the 735XT may well be a red herring here. OpenWeatherMap actually sends back specific day/night weather codes (ending in "d" and "n", respectively), but it's still possible that I've messed something up in that area.

    I've asked the user for a .fit file recorded in his location, so hopefully I'll be able to get to the bottom of this soon.