You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a whole-sign text rectangle tag is used in a multi-page message pattern in the message composer, IRIS will insert the text from the composer fields incorrectly, leading to overlapping text on one page of the message, and leaving other page(s) blank. For example, using the following message pattern:
[tr1,1,0,0][np][tr1,1,0,0]
will produce:
TEST 1[nl]TEST 2[nl]TEST 3[tr1,1,0,0]TEST 4[nl]TEST 5[nl]TEST 6[np][nl][nl][tr1,1,0,0]
Looking like this in the preview and on the sign:
Page 1
Page 2
This does not occur without the [tr...] tags, for example:
[np]
produces:
TEST 1[nl]TEST 2[nl]TEST 3[np]TEST 4[nl]TEST 5[nl]TEST 6
Which looks like:
Page 1
Page 2
Interestingly, this behavior also does not appear when using a non-default font tag. For example:
When using the default font in a font tag, however, it produces the issue (like the first pair of images). In that case, this message pattern:
[fo11][tr1,1,0,0][np][tr1,1,0,0]
produces the following MULTI string:
TEST 1[nl]TEST 2[nl]TEST 3[fo11][tr1,1,0,0]TEST 4[nl]TEST 5[nl]TEST 6[np][nl][nl][tr1,1,0,0]
This behavior has been observed in several versions back to at least 5.42.2 and can be replicated in the current version (5.49.0). Hopefully it is just a minor error in handling the input from the composer fields. If you have any questions or would like more testing, just let me know.
The text was updated successfully, but these errors were encountered:
When a whole-sign text rectangle tag is used in a multi-page message pattern in the message composer, IRIS will insert the text from the composer fields incorrectly, leading to overlapping text on one page of the message, and leaving other page(s) blank. For example, using the following message pattern:
will produce:
Looking like this in the preview and on the sign:
This does not occur without the [tr...] tags, for example:
produces:
Which looks like:
Interestingly, this behavior also does not appear when using a non-default font tag. For example:
produces:
And looks like:
When using the default font in a font tag, however, it produces the issue (like the first pair of images). In that case, this message pattern:
produces the following MULTI string:
This behavior has been observed in several versions back to at least 5.42.2 and can be replicated in the current version (5.49.0). Hopefully it is just a minor error in handling the input from the composer fields. If you have any questions or would like more testing, just let me know.
The text was updated successfully, but these errors were encountered: