search

peterhinch / micropython-font-to-py

A Python 3 utility to convert fonts to Python source capable of being frozen as bytecode
MIT License
368 stars 67 forks source link

Easy method of adding a margin? #30

Closed T-Wilko closed 4 years ago

T-Wilko commented 4 years ago

Hi Peter,

Just started using the writer.py to go hand-in-hand with a large epaper screen I'm working on. I noticed upon first use that the text of the first line begins at (x,y) = (0,0), which makes it a little unpleasant to look at and can sometimes be impractical.

I've read through the writer.py and to me, it seems that there isn't an easy method of setting horizontal and vertical margins. Is that correct?

If so, what would be the easiest way to add variable/s that would allow margins but still retain all the word wrap functionality?

Thanks, Thomas

peterhinch commented 4 years ago

There isn't a built-in way to do this. I guess you'd need an inner rectangle with size smaller than the physical display with text logically constrained to that. Rendering would be to the outer physical rectangle. This is a new request so is not something I've considered.

I want to keep the Writer class minimal so would prefer to see functionality added by subclassing, but if you submitted a PR based on that approach I would certainly consider it.

T-Wilko commented 4 years ago

Okay, no worries. When you say subclass, do you mean a separate file entirely? If so, I think I'll look into writing a writer_extended.py that is a little less lightweight but has some features that I think are important for rendering text to screens (such as margins, line start coords, etc.). I'm not sure if you'll be particularly interested in adding it to your repo but I'll be developing that sort of driver anyways for my project.

peterhinch commented 4 years ago

I meant to write a class derived from Writer. One option is to consider modifying the CWriter class. This keeps Writer lightweight. Another option is a subclass in a separate file. This has a couple of advantages. It keeps the API for the existing classes unchanged and avoids any extra overhead compiling writer.py.

The best solution rather depends on how much code is added, and without detailed study I haven't really got a handle on that.

T-Wilko commented 4 years ago

I see. I'll take a look into building up a subclass in a separate file and get back to you when I'm done with a pr. Thanks!