Please provide a full sample sketch that compiles so that I can make sure I see what you are seeing.
(I had to do a bunch of modifications to the code you posted to get it to compile)
A few things that you should look at:
You don't need to redefine the text areas over and over again.
If you don't need them to change, put them up in setup() vs in loop()
or you can use the constructor to define them:
gText t1 = gText(x, y, columns, rows, font, mode);
which for t1 would be:
gText t1 = gText(0, 0, 7, 1, SystemFont5x7, SCROLL_UP);
You don't have to specify SCROLL_UP as that is the default.
I think what is probably causing the issues/confusion is that when using the system5x7 font,
there are not 24 characters across the display. There are only 21 (and a little bit) so really only 21.
There is also a maximum of 8 rows of text for that font.
Text areas 3 and 4 are too large for the display and the location specified.
For both t3 and t4 there is not enough room for 24 characters starting at X pixel 0
For t4 there is not enough room for 6 rows of text starting at Y pixel 24
(from y24 to y63 there are 40 pixels which is 5 rows/lines)
and then the rows of t3 and t4 overlap on the display.
The DefineArea() calls are failing and when the parameters are bad, it gives you a text area that
is the entire display.
Not sure what the intent was, but the t2.CursorTo(14,0) call is attempting to position
outside the text area.
The t2 text area was defined to only be 8 characters across but the CursorTo() is
is trying to jump to column 14. (column 7 would be the highest available)
Currently, the code does not sanity check column,row parameters so funny things
can happen if you try to position outside the text area bounds.
If you don't want to have to figure out the columns and rows in a text area you can
either used the predefined areas or specify the bounds of the text area in pixels instead.
The only draw back if you use pixels vs rows/columns is that you cannot specify the
font at the same time you define the text area and will have to specify the font for the text area
using a separate SelectFont() call.
The included HTML documentation has more details on the api calls and their parameters.
If you look at the v3 documentation you will see that there is a return value for DefineArea() that
indicates whether or not the call succeeds. I will caution you that the return status values are about
to change. In v3.1 all the return codes will be much more consistent than in v3
In 3.1 a 0 status means success and a non zero is a specific status code. This is not the case in v3.
I only only bring this up as a caution if you decide to look at the return value since v3.1 will
break any code that looks at the return values.
I'm always very concerned about backward compatibility but this is a case where there really wasn't
an option to preserve it and provide the needed new functionality going forward.
--- bill