-
Handling Java’s special characters when splitting paragraph text into lines
Splitting paragraph text into lines from one layer on a second text layer on source text works fine like this:
thisComp.layer(“paragraph_text_layer”).text.sourceText.split(“\r”)[0];
The paragraph source text from layer “paragraph_text_layer” is split by “carriage return” and then referred as line [0] for line 1 and so on. All this works fine for everyday text.
But how can you handle all Java’s special characters that can randomly be contained?
Is there a quick way to replace them before splitting the text to achieve correct splitting and put them back in place afterwards?
-
9 Replies
-
Which special characters are you referring to?
-
.*+?^${}()|[\]\\
…and perhaps a few more. All characters that have dedicated function within Java.
Because they make the “carriage return” criteria “/r” causing a malfunction or inconsistency.
Whenever there is one of those special characters in the paragraph source text.
I searched the web and found something like this to “deactivate” them within the string variable:
function escapeRegex(string) {
return string.replace(/[.*+?^${}()|[\]\\]/g, ‘\\$&’);
}
But afterwards there has to be some kind of replacement of this deactivation so the text is displayed correctly again.
-
I’m not seeing any issues caused by any of the characters you listed while using .split(“\r”).
-
Thank you for checking, curious.
Here comes my test string:
aäb cde fgh ijk lmn oöp qrsß tuü vwx yz AÄBC DEF GHI JKL MNO ÖPQ RST UÜV WXYZ !”§ $%& /() _=?* ‘<> #|; ²³~ @`´ ©«» ¼× {} #xyz 1.xyz, ff fi a
-
If I paste that into a text layer and do .split(” “), I get 35 little strings, as I would expect.
-
Thanks again for testing with my string, Dan.
That sounds plausible, your split criterion is a space ” “.
But what if you do the split with “/r” for “carriage return”?
There should not be any carriage return in my test string yet.
Imagine a user inserting my test string into a paragraph text and then reformatting it by hitting the carriage return key any number of times.
In this case the expected number of lines (strings) generated is not what you would expect because my test string contains special characters messing up something about the line count, I guess.
I am looking for a workaround regarding special characters messing up the number of custom “carriage returns” when splitting is done with “/r”.
Since a user hits carriage return any number of times, the resulting number of lines should match his hits and thus be correct in the end.
-
No carriage returns, many carriage returns, with .split(“\r”) it all comes out as expected…
-
Thanks Dan!
At the moment am designing MOGRTs on Mac Os for Premiere Pro, that are used mainly in a PC environment.
Perhaps the solution for my Problem can be found somewhere out in the Unicode Bermuda Triangle?
-
Possibly. Sorry I wasn’t able to provide the info you’re looking for. I wasn’t able to observe any issues with those characters.
Reply to this Discussion! Login or Sign Up