wrapping error in graphics.printf

[ericabxy]

There is apparently an off-by-one error in function "love.graphics.printf". In my test case I draw two boxes of 8x8 characters intended to wrap at 64px (eight characters wide). The box on the left is drawn with a "limit" parameter of 64, and the box on the right is drawn with a "limit" parameter of 63.

With LÖVE, the characters in the left box are allowed to exactly fill the 64px limit before wrapping, while of course in the right box the eighth character would exceed 63px and thus wraps instead.

With Lutro, the characters in the left box fill the 64px limit and one more character is allowed to be printed before wrapping. The box on the right is allowed to print the eighth character, exceeding the 63px limit. Both diverge from expected LÖVE API behavior.

Printf wrapping was apparently implemented to fix issue #77.

printfwrap.zip

[ericabxy]

I had some time and took a deeper look into the painter pipeline. "pntr_print" checks whether the next character position exceeds the "limit" parameter on line 453. Tried changing the operator to ">=" (patch file attached). This causes Lutro to print the left box correctly, but still diverge from LÖVE behavior with the right box. The current procedure seems prone to overprinting the wrap limit.

In a different patch, I carefully moved the wrap limit check before the call to pntr_draw and duplicated the expression "srect.width + font->extraspacing". This appears to solve the issue and match behavior with LÖVE, but the repeated code is a concern and I can guess at some unforseen problems (is there an edge case where drect falls out of sync with the procedure because it wraps early? Should extraspacing not be included in the early wrap check? Should the wrap check still occur after pntr_draw but make a best guess whether the next character's width would exceed the wrap limit?).

greater_than_or_equal.zip
preemptive_wrap_check.zip