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

[BloodRagg]

Originally Posted by NiLuJe

Released v1.16.0!

Mostly minor tweaks here and there, and a few new features as discussed earlier .

I'm back : found that -q is not respected on error.

[NiLuJe]

@BloodRagg: Which error(s), specifically?

By design, it should only inhibit *non-critical* errors . (By non-critical I mean anything that doesn't lead to an early abort).

[BloodRagg]

Originally Posted by NiLuJe

@BloodRagg: Which error(s), specifically?

By design, it should only inhibit *non-critical* errors . (By non-critical I mean anything that doesn't lead to an early abort).

command line syntax errors , I have a number of while/for loops running in a script, they call fbink a lot But now and then some fall out of favor depending on the input stream its parsing and then all hell breaks loose. (given that your wonderful tool comes with a shitload of switches and accompanying texts).

My logfile of 100k became like 40mb, its annoying if it happens but nothing critical.
If you have a solution that would be great

[NiLuJe]

What kind of syntax error? The kind you could avoid by flagging the end of your own arguments with a "--" (this is getopt), or the kind where your only hope is to throw stdout & stderr to the void?

(Because yeah, syntax errors would fall into the "critical" category ).

[frostschutz]

Is it possible for fbink --truetype to return an error when there was not enough space to render the text completely? Or for this info to be included in --coordinates?

What I'm actually trying to do is determine an optimal font size to render text to a given rectangle. But I can't do it reliably if fbink won't tell me whether the text fit or not.

It would also be interesting to get feedback on the number of times fbink decided to wrap.

Or maybe I'm going about UI design the wrong way... and I should just hardcode it. ;-)

[sherman]

Originally Posted by frostschutz

Is it possible for fbink --truetype to return an error when there was not enough space to render the text completely? Or for this info to be included in --coordinates?

What I'm actually trying to do is determine an optimal font size to render text to a given rectangle. But I can't do it reliably if fbink won't tell me whether the text fit or not.

It would also be interesting to get feedback on the number of times fbink decided to wrap.

Or maybe I'm going about UI design the wrong way... and I should just hardcode it. ;-)

It should be possible.

From memory, there's a measurement pass to test fit, and truncate if necessary. Just a matter of getting that information to the caller. Same with the number of lines.

(It's been a while since I implemented this, then NiLuJe has made changes to the code since, so I'm a bit fuzzy on exactly what's possible...)

[sherman]

Just had a refresh look over the code. Definitely will be possible. Just a matter of figuring out an implementation. @NiLuJe would be best person to figure it out.

As an aside, Once I started using the OT capability, I've come to regret using margins to determine the printable area. In hindsight, an x,y,w,h system might have been better. (as seen by my arithmetic gymnastics here: https://github.com/shermp/Kobo-UNCaG...uprint/eink.go)

[NiLuJe]

IIRC, it returns 0 as a top margin when the drawing area is full.
On the CLI, you can get that either as a status code or on stdout, via the linecode/linecount flags.

That's OTOH, so, err, take that with a grain of salt ;p.

That's not exactly what you want, though, because if it happens to fit perfectly without truncation, it can perfectly well return 0 too, it just means there's no room for another line, not necessarily that the last one was truncated...

@sherman : in this case, as that looks fairly specific to the OT codepath, maybe changing the return type to a Struct with everything you need would be less clunky than the "chuck it somewhere, quite possibly a global, and access it via an accessory function" approach taken by the last rect stuff...

[BloodRagg]

Originally Posted by NiLuJe

What kind of syntax error? The kind you could avoid by flagging the end of your own arguments with a "--" (this is getopt), or the kind where your only hope is to throw stdout & stderr to the void?

(Because yeah, syntax errors would fall into the "critical" category ).

When I run into it again, ill debug and post the used syntax. Thanks

[NiLuJe]

@BloodRagg: I went a wee bit overboard on diagnostic messages, so current master will be extra verbose in that regard .

That said, unless the flags themselves (or the values) are dynamic and possibly broken, most of those could be avoided by enforcing the end of option parsing with a double dash, i.e., fbink -x0 -y0 -- ${text} will ensure whatever's in $text will never go through getopt, and will be passed as-is to print .

[NiLuJe]

@frostschutz: Okay, added some various shenanigans, so -l, --linecount is now in an eval-friendly format instead when used with -t, --truetype, and it includes the amount of lines initially computed, the actual amount of lines rendering took, and whether that ended up truncating the string at one time or another.

You can also skip the rendering pass to make that cheaper, but this will *not* catch every possible truncation, especially with broken metrics.

c.f., the API docs for more details ;).

(For example, the same string, at the same size, can return next_top=0;computed_lines=10;rendered_lines=0;trun cated=0; for a compute only run, but next_top=0;computed_lines=10;rendered_lines=9;trun cated=1; for a full run, as truncation could only be detected at rendering time, because of broken font metrics.)

@sherman: I went with an extra optional struct pointer instead of changing the return type, as I figured this would be less annoying to wrap for FFI stuff, and less annoying to update for API users. And, incidentally, less annoying for the internal handling in fbink_printf ;).

[frostschutz]

Thanks a lot, NiLuJe! I will test it and report back. :-)

[BloodRagg]

If I print to a screen on a different Kobo can I assume it prints correctly ?
Does this mean I still gotta compensate for the input coordinates ?

[NiLuJe]

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

[frostschutz]

@NiLuJe:

everything seems to work great so far (using --linecount --truetype and using that to search for best fit).

There seems to be a problem with starting / trailing newlines though. Well, this occured randomly during testing, I don't expect to be using trailing whitespace normally.

Starting newline (followed by a paragraph of lorem ipsum) causes failure:

[FBInk] Max allowed line width exceeded!
[FBInk] Curr LW: 1046   Max Allowed: 1044!
Failed to print that string!

Trailing newline causes empty square (as if missing character) to be drawn onto the screen.