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.
It seems like there are still issues with layout and geoTextCOMP in the latest experimental release.
To get some nicer fontAnimations I wanted to use the layoutText method of the geoTextCOMP.
In here I use a scriptDAT and CHOP where the scriptDat is only outputting each character and the scriptCHOP is outputting the origin of the character.
This behaviour is showing when using a duplicate or the target geoTextCOMP.
It is still is pretty much broken
I can send you the generator via email if you want to take a look at it, but as I said in this example it is really only printing out the result.
PS:
Gets worse when trying to use other alignemnt modes:
I created a really basic example without the other code I had floating arround:
(Also, changes to the layoutParams of the geoTextCOMP do not trigger a recook of the scriptDats.
Thanks for the report. I think the basic issue is that the alignment is being applied to the glyphs twice.
The layout function includes adjustments for the top/center alignment when it outputs the positions for each glyph, but when the geo text reads those lines back in from the spec chop it doesn’t know the alignment is already included and tries to re-align each character again.
If you read the text back into a second geo text comp where the alignment is left/bottom than I think you’ll get the original layout you expect.
I agree this is a little confusing and I’ll need to think about it a bit before I’m sure on what the best solution is.
Regarding the cooking issue: the layout function was originally meant more as a one-off call, so it does not currently setup the dependencies to automatically re-cook the script dat when the geo text’s parameters change. I will take a look into changing that though since it makes sense that it should re-cook in the setup you are using.
The seconds geoTextCOMp is set to left-bottom, geotext1 is set to center-center.
I would have though that using the definitionDAT should just ignore all the font settings alltogether (or at least automated stuff like alignment and wordwrap) as the aim of the functionality is to be fully in control of these elements.
Sorry, it is a little more complicated than I suggested with using the second geotext.
At the moment, the layoutText function is just returning the raw glyph positions from slug which include the horizontal alignment, but not the vertical alignment which is usually done by touch afterwards. Slug always puts the base of the first line at zero and subsequent lines below that which is why it looks like that in geotext2.
The original concept with the specification dat was to basically act like a more efficient replicator for the comp. This meant that each line of the spec dat is an independent block of text except that the page anchor is at the given position (tx, ty, tz) rather than the origin.
So, when you set right alignment in the spec dat, the text is positioned on the right side of the layout box that has it’s bottom-left anchor at the tx, ty pos for that line.
This got messier when we started using individual lines of the spec dat as parts of the same text block i.e. when you use the append column or position individual characters like you are doing. The role of the tx, ty and alignment features are a little less clear in those cases.
As far as changes are concerned: I’m still thinking it over, but I think the layoutText function should at least be updated to factor in the vertical alignment more consistently i.e. include both vertical and horizontal alignment.
Assuming those changes, I’m also wondering if the spec dat needs a special mode that assumes alignment is already baked into the tx, ty position.
Hi Rob,
thanks for the input. This kina of starts to make much more sense now. Basicly each row of the specDAT is kinda of to be understood as its own instance of a geoTextCOMP, with its own area and alignment.
Based on that I found a somewhat workable workarround in reducing the Layout Box Size to 0 on the second geoTextCOMP and the alignment to top-left, which seems to give me an at least reproduceable layout I can then continue working with:
Hi @robmc
Thanks to your input I was able to haggle my way arround the initital limitations as everything became much clearer.
It seems that the textpadding parameters are broken in SpecCHOP-Mode.
In itself, paddingl to paddingb work fine with the builtin parameters, but when using a specCHOP, only paddingl works correctly. r, b and t will be ignored geoTextPadding.tox (702 Bytes)
