The GeoTextCOMP in combination with the specificationDAT seems to be completly broken.
Here is a file with 4 test-cases seen in this image: BrokenGeoTextCOMP.toe (5.2 KB)
Top Left: Not using SpecDAT, WordWrap on. All fine.
Top Right: Parsing Escape-Sequences and WordWrap activated. \n results in the string being doubled.
Bottom Left: Using append in the spec-dat and using \n for newLines. TextAlignment set to bottomLeft.
Bottom Right: Not using escape characters and alignment set to Top Left (sorry, but lol.)
Thanks for the report. There was a bug with strings that ended in line breaks that caused the last line to be rendered twice and this has been fixed now.
The other issue is an incompatibility between the append mode and word wrap. Unfortunately these features cannot feasibly work together based on how the underlying text library works and we’ve added a new warning to make that clearer. The only way I’ve seen it done is to limit each line in the spec dat table to a single character.
I also noticed in the your projects that you seem to be trying to enable bold text for specific lines of text. Unfortunately, that is not supported in the current release because bold is actually a different font and the component only supports rendering a single font at a time.
However, we have some new features coming in the next experimental that will allow you define multiple fonts in each component and then use the spec dat or formatting directives to change the font for specific sections of text. This will allow for bold, italics, etc for single words or lines inside a block of text.
Hi Rob, thanks for the quick response. Glad the bug is fixed.
A shame that it is not working together nicely, but I suppose this can also be archived using directives.
Regarding the bold-part: I was not 100% about the state of that feature as I vaguely remembered this tpic being discussed somewhere so quickly wanted to test the current state, which also resultet in me finding the bug, so no worries there.
The solution using single-characters for linewrap is also faulty though as shown here (When wrapping, the first line is also doing a newLine, jumbling the layout.):
Which is a shame as I use this and the phaserCHOP to create some neat-looking text-animations. I suppose I can generate the positions manually using the textBounding-Methods of the GeoTextCOMP.
EDIT:
But it seems like there is also another issue. Here is an Example using LineWrap, set to Top Left, not specificationDAt or similiar used:
Thanks for the additional examples. I think I tracked down another issue with the single-character spec dat and word wrap that I’ve fixed now. The vertical alignment was relying on some undefined memory that caused the appended text to jump down when word wrap is enabled.
I’m not as clear what is going in the lower example with geotext3. I tried to recreate it with the parameters I can see, but it doesn’t really match up with your view.
