New Resizable Font?

[gfwilliams]

Posted at 2018-06-01 by @gfwilliams

The existing vector font in Espruino really isn't that great, and it led me to look at some other options on this thread.

It turns out rather than storing a filled font, you can store a 'stroke font' that's just made out of lines. It takes half amount of memory and looks pretty smooth.

Below is an example, drawing Espruino's existing vector font up the top, followed by the same stroke font at different line widths below. You can see it scales down nicely, as well as giving you options for how 'bold' it is.

How does everyone feel about this? It'd be replacing the existing vector font, so might mess up the formatting of existing projects.

Some notes:

• It uses half as much flash memory
• You can choose the line width you want
• It's faster to render when drawing single pixel width fonts
• It's slower for wider line widths, and there is some overdraw (which is more of an issue on displays with low bandwidth like the colour LCDs)
• There are other font styles available as well (google 'Hershey fonts')

---

Attachments:

• fonts.png

[espruino-discuss3]

Posted at 2018-06-01 by @yerpj

Can the old font and new resizable font cohexist ?

It's slower for wider line widths, and there is some overdraw (which is more of an issue on displays with low bandwidth like the colour LCDs)

I think that this could be a problem. When using UI such as displays, the refresh rate is often critical for the user experience

---

Posted at 2018-06-02 by @MaBecker

Wow this sound great to me and I am a big fan of your resizable vector font as this is one of Espruino's unique features.

Like this very much about the new resizable font:

It uses half as much flash memory
You can choose the line width you want
It's faster to render when drawing single pixel width fonts

Well things always change.

What about: you keep g.setFontVector(s) and calculate the scaling factor to have a backward like compatibility as this could help not to mess up with the formatting of existing projects.

---

Posted at 2018-06-04 by @gfwilliams

When using UI such as displays, the refresh rate is often critical for the user experience

Yes - however the drawing should work fine on anything with an internal buffer, and if I'm honest the displays with external buffers have always been too slow, so I doubt this will change matters :)

Overfill could really be improved with a bit more work (supporting irregular polygon fills, and converting wide polylines into polygons). I guess there probably needs to be some benchmarking done.

What about: you keep g.setFontVector(s) and calculate the scaling factor to have a backward like compatibility as this could help not to mess up with the formatting of existing projects.

Yes, absolutely - that'd be the plan. It's just if you were expecting some text to be a certain width