Eink Framebuffer Update Trigger

[handyguy]

Thanks again! fbink is certainly more robust and powerful.
Wondering about using -pr options to pad text left and right. They don't seem to do anything when used with a font library. I can't use the -c option as there is other stuff elsewhere on the screen.
e.g.
fbink -t regular=/usr/java/lib/fonts/Caecilia_LT_65_Medium.ttf,px=35,bottom=1410,format "Hello world!" -me

if fbink overlays a longer previous text on the same line, bits of it are left after the new line is displayed. I could pad a variable number of blanks on either side of the new text, or write a blank line beforehand, but that seems tedious - is there an easier way to have fbink pad out blanks left and right of the text when using a tt font?

I am trying to keep screen writing as simple as possible to maxamize battery life.

[NiLuJe]

The OpenType codepath handles positioning completely differently than the fixed cell codepath (margins in pixels, instead of row/col +/- pixels).

As such, some of the more esoteric features available w/ cell rendering aren't supported. Padding (left or right) happens to be one of those things .

(The API documentation for print_ot should have the exact list of supported settings. The CLI tool's help message has a matching "Honor <such and such> flags" line, too).

Font metrics and weird (and not so weird) corner-cass being what they are, what you're asking for is actually slightly tricky to reliably compute *without* rendering the line first. Especially with non-monospaced fonts . (Conversely, it's fairly trivial with fixed-cell, because we know the absolute amount of cells in a line, and that every glyph will fit in one, and that every cell will have the same size).

Depending on what exactly you're doing, the easiest workarounds would be adding a few blank spaces on the edges and/or playing with the margins.
(i.e., unless you're in backgroundless mode, the full drawing area will be background-colored, preventing overlaps if you're reusing the same margins (EDIT: Nope, that was a lie ^^)).

You can probably fine-tune the amount of padding needed via the "compute" feature, which will report the amount of lines that would have been printed, and whether it had to be truncated. While the --coordinates flag will report the actual bounding box of the whole thing.

[NiLuJe]

That said, see my latest edits, re-using the same margins should ensure no overlaps, *unless* you're in backgroundless mode. (EDIT: Or not . See next post).

So, I'm probably going to need a bit more context if that doesn't help .

[NiLuJe]

Oh. Except what we ultimately blit to screen is limited to actually useful content, so the edges of the drawing area are left alone.

I guess I could make the "background" content between the text and the edges of the drawing area be rendered for the amount of effectively printed lines.

Holiday season being what it is, I won't have time to look into this for a few days, though .

(Even this is written in a rush, I may be misremembering how all of this works internally ^^).

[NiLuJe]

Yeah, after a quick look at the code on mobile, I can probably cobble something up when I get back home .

[NiLuJe]

Okay, master now has a few extra padding settings (via a new padding suboption) when rendering OT/TTF fonts .

[handyguy]

cool! thanks!