Sometimes automatic line breaks start at the wrong x-position about litiengine HOT 6 CLOSED

I recently added UI resizing and I've noticed that I can get it to reliably happen for all of my text boxes, just at different sizes. I think the textbox size that it happens at changes for different fonts/strings. I took this GIF with just whatever the default Java font is when you do new Font(null, Font.PLAIN, 28):

I also recreated this issue with the "Monospaced" font (Using "Monospaced" instead of null in the Font constructor).

from litiengine.

Hi LITIENGINE community,

Can I make my first contribution by working on this issue?

I discovered the same cause that was already mentioned in a bug description: negative x position is produced by Align.getLocation(width, objectWidth) when a string line width (objectWidth) exceeds available space (width). This affects not just the LEFT but all values of Align. Similar issues occur with Valign enum:

If these lines are removed:

position gets clamped:

However, two tests fail:

AlignTests > getLocation_InPoint(): expected: <-1.5> but was: <0.0>
AlignTests > getLocation_OffPoint(): expected: <0.45> but was: <0.0>

Both alignment enums are used not only in GuiComponent.renderText() (related to this issue) but also in PhysicsEngine, CollisionEntity, and direct calls of TextRenderer methods. Is it necessary to separate text and entity alignments? For example: create a dedicated TextAlign enum, or just use a common Align but rename getLocation() to getTextLocation() and add getEntityLocation().

Either way an expected location behavior should be determined for all alignment values.

from litiengine.

I can reproduce this, but couldn't pinpoint the source of this issue.
What I can say for sure is that it depends on the font used due to the differences in glyph width:

from litiengine.

I remember also having issues with text rendering in java in one of my own projects.

I had to render the text using a GlyphVector to calculate bounds and stuff because it would just be wrong very often, however I've never seen it wrong by that much.

Just from a visual glance, it looks like the text's x-coordinate is being set to -(w*0.5) where w is the width of the line of text being rendered.

from litiengine.

Hi @hedfol , thank you for your detailed assessment! We welcome your contribution in this regard. I would neither create separate classes nor methods for this, but an overload to the getLocation method with an additional boolean parameter that lets the user decide which behaviour to choose. Since the current logic seems to be assuming the entity case, we should leave the uses of getLocation in entities untouched and only replace the uses in text scenarios with the new overload.

from litiengine.

Thanks @nightm4re94 , that's an easy solution! I've created a PR with suggested changes.

from litiengine.