FBInk: A small tool/library to print crap on your screen!

[NiLuJe]

@frostschutz: Huh. On the off chance this is font-specific (prooobaaably not, but who knows ;p), what font is this?

EDIT: And at which size, while I'm there . Actually, the exact full set of arguments could be helpful, in case it's really font and/or size and/or content specific...

[frostschutz]

Oh, sorry... in this case it was Vera.ttf from https://www.archlinux.org/packages/e...am-vera/files/ (md5 785d2fd45984c6548763ae6702d83e20) but it also happened with other fonts I tried

fbink --clear --truetype regular=vera.ttf  $'\nx' # failed to print
fbink --clear --truetype regular=vera.ttf  $'x\n' # prints with empty square

[BloodRagg]

Originally Posted by NiLuJe

@BloodRagg: Not sure I follow, sorry . More details?

Are the coordinates different per device ? Mine has
Upper right = 0,0
Bottom left= 1080,1440

Only have one device, makes testing more difficult

[NiLuJe]

@BloodRagg: Oh, yeah, Each model is different. Different screen resolutions, different input quirks ;/. There's a bit of overlap sometimes, but not always.

Plato might have the most concise way of dealing with that, if you need inspiration.

[NiLuJe]

@frostschutz: Oh, yeah, the leading linefeed one was actually triggering an underflow and then a nasty loop.

I think I have a fix for both, just need to do some more testing tomorrow to make sure I'm not making everything else worse ;p.

Thanks for the report .

[heyman]

i still don't know what the title means, "print" what?
we need native speakers in this forums..

[NiLuJe]

@frostschutz: Pushed the linefeeds fixes .

@sherman: They're here. I *think* that's a somewhat sensible approach, but you're probably more familiar with this logic than I am. It's mostly all related to not calling u8_dec when the index is 0, as it would happily look *before* the buffer, and underflow the index.

Besides the test-cases provided by @frostschutz, the only other edge-case I could actually trigger is with a single character *right* above the size limit. I couldn't actually trigger a crash, but I did get an underflow, and by chance it happened to find a bogus break (very) soon after the wrapped-around value, so it mostly slipped through the cracks unnoticed.
Now it reliably aborts with the proper "you blew the LW" error.

[sherman]

Originally Posted by NiLuJe

@frostschutz: Pushed the linefeeds fixes .

@sherman: They're here. I *think* that's a somewhat sensible approach, but you're probably more familiar with this logic than I am. It's mostly all related to not calling u8_dec when the index is 0, as it would happily look *before* the buffer, and underflow the index.

Besides the test-cases provided by @frostschutz, the only other edge-case I could actually trigger is with a single character *right* above the size limit. I couldn't actually trigger a crash, but I did get an underflow, and by chance it happened to find a bogus break (very) soon after the wrapped-around value, so it mostly slipped through the cracks unnoticed.
Now it reliably aborts with the proper "you blew the LW" error.

Looks like it should be ok. Bit of an oopsie there wasn't it. I might have been inclined to just strip leading/trailing linebreaks, but your solution is probably more correct.

I'm writing this while awaiting a flight at San Diego airport, so take my "review" with a dash of salt...

[NiLuJe]

@sherman: Thanks! (and have a safe flight ).

[NiLuJe]

Released v1.17.0!

A fair amount of goodies in this one .

There's the on-animator mimic mode used by KFMon to replace the boot progress bar, which didn't make the latest release because that basically started as a random post-release experiment ;p.

Error handling in the CLI tool is now extra verbose, as discussed above.

There's the line-breaking feedback discussed above, too.

Also on the OT/TTF side of things, the font size can now be specified as a decimal, which should allow finer-grained control over the final rendering .

On the fixed-cell font rendering side of things, Spleen has been updated to 1.0.5, and a couple of Amiga fonts have been imported (Topaz+ A1200 & MicroKnight+), as well as the VGA variant (8x16) of the IBM font.
The LF glyph is now always replaced by a space, to account for fonts where it is visible.

There's a bunch of minor performance improvements all over, but especially for the fixed-cell font rendering.

In the continuing trend of "RGB565 is the worst", there's also a fix for a sneaky color accuracy issue in some corner-cases, that mainly affected progress bars @16bpp.

[DNSB]

Originally Posted by heyman

i still don't know what the title means, "print" what?
we need native speakers in this forums..

Would you have preferred "display crap on your screen!"?

[NiLuJe]

Released v1.18.0!

A few minor fixes, and the possibility of specifying OT/TTF font sizes in pixels .

[frostschutz]

fbink reading from stdin can lead to some unexpected results

[FBInk] Codepoint U+5348 is not covered by this font!
[FBInk] Codepoint U+524D is not covered by this font!
Next line should start @ row 240
[FBInk] Codepoint U+7B54 is not covered by this font!
Next line should start @ row 241
Next line should start @ row 242
Next line should start @ row 243
[FBInk] Codepoint U+30B3 is not covered by this font!
[FBInk] Codepoint U+30C3 is not covered by this font!
[FBInk] Codepoint U+30D7 is not covered by this font!
Next line should start @ row 244

like huh, what's going on

while read line
do
    # do something with line
    fbink "$line" # works with fancy options too
    fbink --clear # reads all other lines and prints them by itself (or not, if not ASCII)
done < somefile.txt

now I end up `< /dev/null` all fbink calls :-}

[NiLuJe]

Yeah, --clear is never actually a shortcut (it's not intended to mean "clear the screen and get out", but "clear the screen before doing whatever else needs to be done"), there's a few workarounds to make it so when positional arguments are involved, but if stdin is not empty, it'll get drained .

So, yeah, either pass a single space as a positional arg, or ensure stdin is empty, which is what happens with your /dev/null redirection .

[NiLuJe]

@frostschutz: Hopefully made that slightly clearer in the help message, and added a -k, --cls flag that *will* always abort early .

Obviously, in your example, unless there's a significant delay between the two calls during a single iteration, what'll happen is that the controller will bundle the two refreshes together, and you'll probably almost never see the line on screen .

Without knowing more context about your use-cases, what would make more sense to me would be a single fbink -c "$line" (i.e., clear the screen, then print $line) .