One Animator, Two Aspect Ratios, Two Different Animations
A social campaign needs one animated headline in two aspect ratios: 1080x1920 with a 42-character headline, and 1080x1080 with a 14-character headline. The designer built the animation on a text layer with a single text animator: Scale 0 to 100 and Opacity 0 to 100, Based On Characters, with a Range Selector whose Offset runs from -100% to 100% over one second, Shape set to Ramp Up. They duplicated the comp for the square version and replaced the copy. In the tall version the characters land almost on top of each other, the last few barely animate, and the pop reads as mush under motion blur at 23.976 fps. In the square version it is a hard snap. The client will change the copy weekly and the brand font must stay editable.
1. Why does the identical animator behave so differently across the two comps? Give the diagnosis with numbers, then rank your fixes.
Read the worked answer
Diagnosis. A text animator has no concept of time; it has a concept of percentage of the text. Animating Offset from -100% to 100% sweeps the whole string in one second whether the string is 14 characters or 42. The visible gap between characters is therefore duration divided by character count:
- 42 characters in 1.0 s: about 24 ms per character.
- 14 characters in 1.0 s: about 71 ms per character.
- One frame at 23.976 fps is 41.7 ms.
So in the tall version almost two characters change per frame and the sweep collapses into a single smear; in the square version less than one character changes per frame, which reads as a crisp sequential snap. The Ramp Up shape compounds it, because its ease is a gradient across a percentage of the string, so on the long string the transition is spread over many characters and never fully resolves.
Fixes, ranked:
- Split the headline into words or two or three chunks on separate text layers and stagger them in time. Predictable, still live text, survives copy changes.
- Keep one layer and drive the Offset with an expression that advances a fixed characters-per-second rate, dividing by the string length so the rate stays constant: offset = -100 + (time - startTime) * cps / charCount * 100, clamped at 100. Now both versions share a per-character rhythm.
- Design the timing for the longest string and hand-tune the short one.
Changing the comp frame rate or stretching the Offset keyframes does not help: it rescales both versions identically and leaves the length dependence intact.
2. The client will send new copy every week. What do you change in how the text is built so the edits stay safe?
Read the worked answer
Keep the text live. Converting to shapes was the tempting route for a specific look, but it destroys the animator, multiplies layer count, slows previews, and makes a weekly copy change a rebuild. If outlines are truly required for a lockup, keep a hidden live text layer next to the shapes as the editable source of record.
Make the layout carry the change:
- Use paragraph text, not point text, wherever the line may reflow. A text box with a fixed width wraps new copy instead of running off frame.
- Avoid manual line breaks and hand-placed spaces to fake tracking. Use tracking and leading; hand-typed breaks break the moment a word changes length.
- Set the animator's Anchor Point Grouping to Character so each glyph scales from its own center. Left at Layer, all characters scale from the layer anchor and the effect looks wrong at any other alignment.
- Keep the animator count low and reuse one animator across both comps. Duplicated, hand-tuned animators are where inconsistent versions come from.
- Budget for the worst case: test with a string 20% longer than the current copy before sign-off, and set the text to shrink or reflow predictably rather than trusting the client to send short lines.
Handoff. Put the editable fields where a non-compositor can reach them, name the text layers clearly, and note the character-count assumption so a future editor knows why the timing was chosen.