Suggested standard approach to font handling

C programming, build, interpreter/VM.
Target audience: MicroPython Developers.
User avatar
pythoncoder
Posts: 3421
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

newb
Posts: 28
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: 3421
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

Post Reply