Storyline360, Animation and GSAP ( Greensock )

interesting news - the coding depends on which characters really used in the text of the complete course (with the same font)

tests are made with Firefox - therefore the "good" view of non-printable characters

decoding

txt = txt.replaceAll("\uE000", "f");
txt = txt.replaceAll("\uE001", "ff");
txt = txt.replaceAll("\uE002", "fi");
txt = txt.replaceAll("\uE003", "fl");
txt = txt.replaceAll("\uE004", "ffi");
txt = txt.replaceAll("\uE005", "ffl");

Example 1: in the course is used "f – ff – fi – fl - ffi – ffl (Stoffflasche)"

Example 2: in the course is used "f – ff – fl - ffi – ffl (Stoffflasche)" <- no "fi" used (same decoding)

=> decode of "fl", "ffi", ffl" has different results!

=> don't use fonts with legatures, if you want to grab the vector text !

=> you can use e.g. font "Articulate" (no ligature at all) for the vector text

Or you could add all the ligatures in an offstage text box in the first slide which would/should make it predictable.

Just read it properly I think I will use Articulate font which would work for this.

Sent from my iPhone

For the SplitText and similar setups..i do think using a non-ligature Articulate font version for the original text field probably is the easiest solution. Good to keep in mind. Whenever you create HTML text with that content...it doesnot matter anyway as its no real Storyline text anymore.

Even better I have to use it in a mock-up of a terminal window and Cascadia Mini has no ligatures.
Sent from my iPhone

Your ligature test.story is very helpfull...as it makes it easy to check whether any given font has issues with them in Storyline.

Math, I was wondering if I can ask to borrow your coding genius mind to help me figure out the screen size refresh code for this slide. It functions like I want on a desktop monitor, but when reduced down the scrolling panel percentages don't work correctly. Here is the example -

https://360.articulate.com/review/content/ce7573c7-fc10-42c8-961e-c0fd17576556/review

My first thought was that it was a Review issue, but testing and publishing purely as Web has the same results. Checking things out now.

Tweenlite you can exchange for gsap as thats included in Storyline now.

As you use a 'FromTo' tween for the scrollArea... easiest is using some static elements and then getProperty to get the exact values to move From and To... making that work in your sample.

OK - that is good advise, will change this to gsap. 

Fixed.

Added a ResizeHandler() that acts on every resize and shows width and height. Thus you can if needed calculate where what needs to be. 

But using a temporary shape to reposition it to on the x is easiest.
Added a fromShape... and in the ResizeHandler a gsap.set is used.
gsap.set(lessArw, { x:gsap.getProperty(fromShape, "x") });
Getting the x from the element.

First attempt though failed... In Storyline shapes, images and groups all have different orientation points or origins. And that makes it going wrong.
The fromShape probably calculates from its center, where a group uses the 0,0 point..thus getting unexplainable positions. Setting both orientpoints to 0,0 or top,left now...

Thats working, so its fixed.

PS.. Gsap code formatting is a bit different then TweenLite/TweenMax was.
All code is backwards compatible, but better to adhere to newest approach.

TweenLite.to(txtArea, .65 ,{y:pos1, ease: "back.out(3)", delay: 0});
gsap.to(txtArea ,{duration:.65, y:pos1, ease: "back.out(3)", delay: 0});

So main difference is all parameters inside the { }. And the duration has a label ;-)

I am so thankful for you sharing your knowledge and expertise on this! I really appreciate you and your ability to figure complex issues out.