id kinda prefer the list-return version - can you adapt it to match?

@FoamyGuy I'll test this sometime in the next few days

I ran several scenarios to sort out the behavior with miscellaneous white space. I found one bug that adds a leading newline. The other two things may be your planned behavior, so my only suggestion is to add a couple lines of documentation to clarify how newlines and leading/trailing whitespace is treated.

Bug?

Input string: text = "THISISasuperlongstringwithnospacesthatwillnotfit"
Output: ['', 'THISISasuperlongstring-', 'withnospacesthatwillno-', 'tfit']
Adds an extra newline at the beginning.

For Documentation

Input string: text = "\t A short \ntest"
Output: ['A short test']
Behavior: Newlines and tabs are obliterated.
(Unrelated to this, I found that label and bitmap_label both ignore tabs. I'll add an issue.)

For Documentation

Input string: text = " Leading and trailing spaces are deleted. "
Output: ['Leading and trailing', 'spaces are deleted.']
Behavior: Leading and trailing spaces are deleted.

Thanks for looking into this @kmatch98!

Definitely a bug on the first one.

I lean toward bug on \ns getting removed as well. It's probably best not to use them if you want the function to do the wrapping, but if the user includes them we should try to keep them if we can. Tabs we can look at once they get fixed in label and bitmap_label.

Agreed about documenting the removal of leading and trailing spaces. For leading spaces the indend0 parameter can be used to add some spaces ( or anything) to the beginning

I'll work on making these changes to fix and document the above.

@FoamyGuy Currently pretty swamped with other stuff so I'm not sure when I'm gonna get to this. If you're fine waiting a bit (looking like a week at least) I'd still be down to review this, but otherwise I won't be offended if someone else reviews it

Okay, I think this is ready for review again. The latest commits resolve the issues noted above in the following ways:

• Very long word results in extra newline at the beginning. This was due to the longword logic always starting on the next line down instead of picking up in the current spot of the line. That coupled with the indent0 value was causing the extra line at the beginning. Newest version just starts right where it's at in the partial line instead of jumping down to the next. This avoids the extra newline in the single long word scenario.

• tabs and newlines removed. Tabs we will need to deal with inside of label and bitmap label. So I didn't do anything specific here for them yet. Newlines no longer get removed, and are now properly respected. So the user can have newlines in the input string to get extra empty lines in the output.

• leading and trailing whitespace removed. This behavior is now documented along with a note about the indent0 and indent1 parameters that can be used to control leading whitespace if desired.

I tested and the this fixes the issues mentioned above. I also verified that the leading and trailing spaces are now retained.

I checked the operation of the indent0 and indent1. I noticed that using the indent1 option always leaves an extra line at the end. Not a big deal, but it's unexpected.

text = "CircuitPython is a programming language"
print(wrap_text_to_pixels(text, WRAP_WIDTH, font, indent0="*", indent1="-"))

Output:

['*CircuitPython is a', '-programming language', '-']

Thanks for these fixes!

Nice catch @kmatch98, thank you! indent1 was getting added an extra time by some code adding partial pat the end an extra time.

The latest commit resolves it, the returned list no longer has an extra item in it.

I verified this update, it definitely solves the problem. Thanks for getting this merged into the library and fixing all these details!

Looks good to me.