Issues

Issue #799 new

Font::getWrap() implementation issues

Andrew McWatters
created an issue

After some testing, Font::getWrap() doesn't seem to wrap strictly to the maximum length provided. Rather, the method attempts to break down segments of text separated by spaces to new lines within the width provided, and allows any "word" too long to sit on a line of its own. However, then the "word" is still permitted to overflow rather than then being broken down by characters.

Writing workarounds for this is entirely possible (rolling your own version of love.graphics.printf and font:getWrap()) but I assume that isn't what LÖVE's developers intended.

Attached are images depicting the issue. The first image (vadventure.png) shows no wrapping taking place within a console. The second image (vadventure (2).png) depicts proper wrapping taking place prior to overflow. However, the last image (vadventure (3).png) displays text overflowing outside of the maximum limit provided (which should not occur), but being cut off by stencil operation, rather than the last segment of text finally being spliced by characters instead of spaces.

Comments (16)

  1. Andrew McWatters reporter

    I'm increasing the priority of this, because this no longer seems like a minor issue considering the potential usage frequency of this function in any given project and the confusion that can be caused by its implementation.

  2. Alex Szpakowski

    I'm not saying the functionality is good, just that it's a little odd for the bug to be marked as major when it's nothing new or game-breaking, as long as you know what to expect. A little text on the wiki would probably help, yeah.

  3. Andrew McWatters reporter

    Alright... well I'll document it on the wiki. I'm just hoping this doesn't get marked invalid, but if this has been how its been for years, I can understand if it does.

    I don't really see another way to properly print wrapped text that doesn't essentially modify the text argument provided without writing your own replacement for this function. I just figured that wasn't the intended design.

  4. Alex Szpakowski

    I'm hoping this doesn't get marked invalid

    I should clarify: I agree that these are valid issues. I think the only reason to close this without resolving them would be if there are technical problems with providing a good implementation which fixes them.

  5. skooch

    How can you define game-breaking? That depends on how extensively the function is used in your game. In our game, text wrapping is used from elements like the console to the tooltips. About half a day was spent tracking why the text wasn't wrapping correctly and spaces would just disappear out of nowhere.

    It's all very well that functionality has remained "pretty much the same" for several years, but what's the point of having a function to do these things, if it can't even do it correctly in the first place?

    We will provide any extra information you may need, and will probably go bug-hunting ourselves. Sorry for the rant, but it's just that bugs that are smaller in some people's eyes, are actually totally annoying and major for others.

  6. Alex Szpakowski

    what's the point of having a function to do these things, if it can't even do it correctly in the first place?

    Lack of documentation is not the same as a bug. Depending on the intention of the person who created the functions, the wrapping issue could either be how it's supposed to work, or a bug.

  7. Landon Manning

    My best solution to this issue would be adding a strict flag to Font:getWrap() that instructs the function to adhere to the max width provided and break long words apart, otherwise allow overflow.

    -- Font:getWrap(text, width, strict)
    local width, lines = font:getWrap("Now this is a story all about how my life got flipped turned up-side-down!", 100, true)
    
  8. Landon Manning

    Toss in a strict flag for that too, I guess? Both reflow and overflow are very valid and useful when dealing with breaking up text. If both can be accommodated, that is the ultimate solution.

    love.graphics.printf( text, x, y, limit, align, strict )

  9. Landon Manning

    Well, if it were strict, it would break at the character before overflowing would occur. That would be a very strict interpretation that doesn't necessarily follow the semantics of any language. if you want to do proper i18n support, that would require a complete overhaul of printf and getWrap which may be out of scope. For individual language support, it might be best left to a library.

    -- strict
    [HelloMyNameIsKa]
    [rai            ]
    
    -- overflow
    [HelloMyNameIsKa]rai
    
  10. Log in to comment