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

[sherman]

Originally Posted by frostschutz

found some bugs:

- font size 256pt is understood as 0pt (integer overflow)?

Um, yeah. Silly me wasn't expecting anyone to want a larger font size. That's an easy one to fix.

- characters missing when using UTF-8 (string length miscalculation)?

Can you provide a test string, and let me know what characters are missing? Are they missing on a line break by any chance?

xyzäöü1234567890 leaves out 890 presumably because 3 umlauts. is worse for CJK characters presumably because 3-4-byte chars instead of 2-byte-chars.

This may be due to string normalization. I may have to look into normalizing the string, or specifying that the caller needs to do it first (It's perfectly valid unicode to store the base character and umlauts as separate codepoints. Normalization combines them to one codepoint). We are using a utf-8 parser, and never assuming max 2 byte characters, so I don't THINK that's the problem.

Otherwise great! I will try to find a way to use this in my FlashCard mod.[/QUOTE]
Thanks for testing. I'm afraid I'm an english only speaker, so it's helpful to get reports from people trying to use different languages!

[NiLuJe]

* Yup, it's an uint8_t, I *think* nothing useful will ever come of >255pt, but I forgot to check, and at the very least we should catch a wrap like that (or just switch to an ushort and forget about it? ) .

* UTF8 handling *looked* sound, but I'll double-check . I did quickly try CJK stuff, but, err, since I don't read it, I failed to notice missing stuff .

EDIT: Too late ;p.

[sherman]

Originally Posted by NiLuJe

* Yup, it's an uint8_t, I *think* nothing useful will ever come of >255pt, but I forgot to check, and at the very least we should catch a wrap like that .

* UTF8 handling *looked* sound, but I'll double-check . I did quickly try CJK stuff, but, err, since I don't read it, I failed to notice missing stuff .

EDIT: Too late ;p.

Do you want to look at it, or should I?

[frostschutz]

Originally Posted by sherman

Can you provide a test string, and let me know what characters are missing?

There are no characters missing, it just stops printing early for some reason.

Print '漢' and it shows 漢

Print '漢字' and it still shows 漢

Print '漢字--' and it shows 漢字

Print '漢字----' and it still shows 漢字

Print '漢字-----' it shows 漢字-

It's like it knows it has to show 2 characters, then calls it quits after processing 3 bytes (which is only one character).

漢字 is six bytes and additional - character only shows up when providing a 7 character string. So instead of showing 7 characters as requested, it shows 7 bytes.

And providing 漢字-- (4 characters string) causes the next character to show up (漢字) because the first character only consumed 3 bytes.

So much for my guess without looking at any code at all

[frostschutz]

@NiLuJe

255pt is actually about the same size as I use here ( flashcard example for 森 character https://www.mobileread.com/forums/at...6&d=1540719095 )

But this is on my H2O, wouldn't it need to be larger on 8"-10" or higher res readers? (Is pt DPI dependent or just pixels?)

This just to illustrate why I wanted to print a huge character... I wouldn't have complained if 65536pt -> 0pt. I just went to 256pt by trial&error cause 32 64 128 was too small after all

[sherman]

Originally Posted by frostschutz

@NiLuJe

255pt is actually about the same size as I use here ( flashcard example for 森 character https://www.mobileread.com/forums/at...6&d=1540719095 )

But this is on my H2O, wouldn't it need to be larger on 8"-10" or higher res readers? (Is pt DPI dependent or just pixels?)

This just to illustrate why I wanted to print a huge character... I wouldn't have complained if 65536pt -> 0pt. I just went to 256pt by trial&error cause 32 64 128 was too small after all

I'll answer, because i know. The size is DPI aware, that's why I chose points, instead of pixels for size, so that users would see (roughly) the same font size, regardless of screen DPI.

[NiLuJe]

@sherman: I'll be busy for the next few hours, so, go ahead .

Initial findings would point to the fact that the various c_index vs. chars_in_str checks are wrong, because c_index is the *byte* index in the string array, while chars_in_str is the amount of unicode "characters".
Since bytes >= unicode chars, drift slowly accumulates as more multi-byte characters are encountered, and we abort the loop early.

Of lesser import, the md parser stuff is also massively not unicode aware, but we already knew that ;p.

----

And, yeah, now that I've checked, I can see somewhat valid use cases for >255pt, so that's an easy fix, at least .

[sherman]

Originally Posted by NiLuJe

@sherman: I'll be busy for the next few hours, so, go ahead .

Initial findings would point to the fact that the various c_index vs. chars_in_str checks are wrong, because c_index is the *byte* index in the string array, while chars_in_str is the amount of unicode "characters".
Since bytes >= unicode chars, drift slowly accumulates as more multi-byte characters are encountered.

Of lesser import, the md stuff is also massively not unicode aware, but we already knew that ;p.

*facepalms*

[frostschutz]

well, I won't complain about the md stuff

I'm happy already to have it work as well as it does, half expected it to not handle megabytes-large fonts but it works just fine

this is a huge step forward, thank you so much

[sherman]

Hi frostschutz,

Here's a test version of FBInk, which hopefully fixes the issues you've raised. Can you test and let me know if it does? Especially the CJK stuff.

It allows for font sizes greater than 255 as well, although be aware, your print area needs to be large enough to support it, otherwise nothing will show on screen.

[frostschutz]

it seems to work fine, thank you

[sherman]

Originally Posted by frostschutz

it seems to work fine, thank you

No problem... It was my own silly mistake that caused the issue in the first place.

EDIT: And PR submitted to NiLuJe

[sherman]

Also, a quick note on the md parser not being unicode aware, from my point of view, I don't think it needs to be. It just iterates over bytes, and if it sees the ASCII '*' or '_' characters, it triggers an action. Otherwise, the text stream is seen as an opaque sequence of bytes, because it doesn't care about them.

In other words, it should handle any input you give it, regardless of whether it's english or not. On the other hand, it has no concept of whether a given language even supports bold/italics, but it's up to the user to figure that one out in my opinion.

[NiLuJe]

@sherman: Yeah, for some reason, I was worried it'd flag stuff in-between multi-byte characters, but no, after a good night's sleep and some testing, things appear to work well (at least with Latin scripts, so, 2 or 3 bytes) .

This just made me mad at Kobo again for their broken libc because I have to swap to a custom busybox shell to actually be able to input utf8 in my terminal, but, oh, well .

[sherman]

Originally Posted by NiLuJe

@sherman: Yeah, for some reason, I was worried it'd flag stuff in-between multi-byte characters, but no, after a good night's sleep and some testing, things appear to work well (at least with Latin scripts, so, 2 or 3 bytes) .

This just made me mad at Kobo again for their broken libc because I have to swap to a custom busybox shell to actually be able to input utf8 in my terminal, but, oh, well .

That's the nice property that UTF-8 has. Any byte outside the ASCII range starts with 1xxxxxxx, so a valid ASCII character will never be found within a multi-byte sequence.