Suggested standard approach to font handling

C programming, build, interpreter/VM.
Target audience: MicroPython Developers.
User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Suggested standard approach to font handling

Post by pythoncoder » Wed Aug 29, 2018 6:58 am

Thank you for reporting your results and for supplying the full cyrillic character set. I appreciate cyrillic_subset lacked the full charset. It was just a demo. I've updated it with the charset you supplied and renamed it cyrillic.

RAM on the ESP8266 is a problem and larger files need to be frozen as bytecode. That's one reason why I retained writer_minimal.py - perhaps I should clarify this in the docs. This file is the old version with redundant example code removed.

Reasons for the changes to writer.py:

The Writer class was originally intended as a proof of concept for font conversion: I anticipated people using it as a template for writing drivers targeted at specific display devices. But it acquired a number of users with SSD1306 devices. Further, the framebuf class acquired the ability to be subclassed and the official SSD1306 driver was adapted to do this. The ability to write display drivers subclassed on framebuf opened up the possibility of Writer becoming generic and usable with any display, colour or monochrome, with such a driver.

Users requested a number of improvements to the Writer class such as support for multiple displays, word wrapping and upside-down display. I have also implemented support for colour displays. All of this has increased the size.

Writer is now generic. In addition to SSD1306 it works with Nokia 5110 using this driver and this Adafruit colour display (driver for the latter to be posted soon).
Peter Hinch
Index to my micropython libraries.

newb
Posts: 43
Joined: Wed Jan 10, 2018 8:19 pm
Location: Bulgaria

Re: Suggested standard approach to font handling

Post by newb » Wed Aug 29, 2018 7:19 am

Thank you for explaining this and for the maintaining the writer class.
It might be connected to my lack of knowledge but I found out that if set font points to odd number, the converted python font is rendered better than if I set even number of points. The pictures I posted are with even number of points. I've re-rendered the font with an odd number and it came out way better.

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Suggested standard approach to font handling

Post by pythoncoder » Wed Aug 29, 2018 7:29 am

Interesting observation. I'll experiment ;)
Peter Hinch
Index to my micropython libraries.

mizu12
Posts: 1
Joined: Sat Sep 14, 2019 8:27 pm

Re: Suggested standard approach to font handling

Post by mizu12 » Sat Sep 14, 2019 9:31 pm

Hi Peter,

Unfortunately it's not easy to find documentation regarding e-paper displays used with micropython, however after long days of struggling I've found this thread:
viewtopic.php?f=18&t=6319&start=10

and succeeded to get my 1.54inch e-paper display working.
I used your font_to_py to convert some fonts and tested their usage with the Writer class, it worked flawlessly.

However I'd like to use huge fonts which unfortunately don't fit into the firmware (and into the RAM) on my Wemos Mini D1.

You suggested on the project's page to use binary font files stored on the flash in that case. Could you give me some hint, how is it possible to use the random access font files? As I looked into there is no such option in the Writer class.

Thanks

Post Reply