search

openfl / starling

Known as the "Cross-Platform Game Engine", Starling is a popular Stage3D framework for OpenFL and Haxe
Other
236 stars 67 forks source link

(Starling 2) TextField.autoSize not working #76

Closed Stortof closed 6 years ago

Stortof commented 7 years ago

Hello guys,

The autoSize property for TextField does not work.

Quick example:

var txt:TextField = new TextField(10, 10, "some text", new TextFormat("Ubuntu", 25, 0xFFFFFF));
txt.autoSize = TextFieldAutoSize.BOTH_DIRECTIONS;
addChild(txt);

output: not text is displaying. It's the same with TextFieldAutoSize.HORIZONTAL or TextFieldAutoSize.VERTICAL

numero15 commented 6 years ago

I got this issue too, you can look at this issue. I found workaround, but it feels a bit messy !

TerryCavanagh commented 6 years ago

Can confirm that this is still happening. I get random crashes anytime I set txt.autoSize = TextFieldAutoSize.BOTH_DIRECTIONS; or txt.autoSize = TextFieldAutoSize.VERTICAL;. :( @numero15's workaround does not fix the issue for me, unfortunately!

TerryCavanagh commented 6 years ago

Oh, I should add: this only seems to affect TTF fonts. Bitmap fonts seem to work fine!

TerryCavanagh commented 6 years ago

(fwiw, I was able to work around my issue a different way, so this is a pretty low priority for me now)

TerryCavanagh commented 6 years ago

Some tangentially relevant info about this one:

I encountered this problem because I was trying to write a Text.width() function. In earlier versions of Starling, I could set the textfield to Autosize, and trust that textfield.width would then give me an accurate result.

Since this bug cropped up, I changed to using textfield.textBounds.width, which seemed to work at first! However, that led to this subtle problem:

kerningbug

kerning2

i.e. for bitmap fonts at least, the sum of individual character widths in a string doesn't always equal the total. (see here for more details: https://github.com/TerryCavanagh/haxegon/issues/212)

The number I actually want to figure out is the end caret position of the string - i.e. the sum of all the xadvance values in the bitmap font xml. I used to be able to get this from the autosize trick. However, textBounds.width instead gives me the width of the generated mesh, which is going to be different from the end caret position if the xadvance and width parameters aren't the same.

Ok, to sum up, a question! Is there a way to get an accurate end caret position in the latest version of starling?

jgranick commented 6 years ago

I guess the question is whether the issue with Starling auto-size is either A.) a bug in porting the library, that's sneakily hiding somewhere, or B.) caused by a minor in OpenFL's TextField, which is revealing itself through Starling. Has anyone tried to figure this out?

jgranick commented 6 years ago

This is resolved in the latest OpenFL dev :wink: