[Tomas Bumbulevičius]

Hey Andrei, thanks for your response. I didn’t had time to focus on this recently, but few thoughts:
1. When contents of file is read as fileObj.read() – I assume its a plain binary read. Then, what to do with that readed bits, how to make them human-readable?
2. Indeed, dollar like $.evalFile is obsolete and doesn’t work if expression language set to new Javascript. While I am looking how to approach this in scripting, if someone hits that roadblock through expressions – be aware that $.evalFile in expressions works only with expression engine set to “Legacy Extendscript”. While its not a new thing, I just figured out it recently.

[Tomas Bumbulevičius]

What I eventually ended up using:
1. Creating EXACT replica of text I want to space out in height. It works as a reference.
2. Calculating the tracking based on Dan’s expression shared above.
3. Linking main text’s tracking property to this value.

It bypasses issue of not updating in viewport. Works on 2021 100%. Thanks again, Dan!

[Tomas Bumbulevičius]

Hey Dan, thanks a lot for your response. This could be a workaround for this indeed, but there is a catch I think.

Do you happen to know the overall logic of how paragraph bounding box works? What is interesting, that sourceRectAtTime is not capable of reading actual text inside the box – it reads whole height of paragraph, disregarding of how many lines there are. I might have confused calling this thing “area text” in the headline 🙂 Thanks!

[Tomas Bumbulevičius]

Andrei, thanks a lot! I agree that object model is irreplaceable if you need to figure out something new, or troubleshoot.

The problem here comes with ESTK is that it is no longer supported on MacOS (unless I missed something https://github.com/Adobe-CEP/CEP-Resources/tree/master/ExtendScript-Toolkit)

Thats where it pushes onto boundaries of not being able to dev on different OS’s relatively “problems free”.

[Tomas Bumbulevičius]

Two years later I am finally completely emptied by unreliability of Visual Studio Code, especially on MacOs.

~ Doesn’t stop at break points;
~ Doesn’t showcase global scope/object model (only local functions are accessible when reached in).

The time spent looking for workarounds is not justifiable when nothing works at all, and the issue is somewhere in the roots, outside of understandable waters.

In the past, this worked well to move from dead end on breakpoints:

$.level = 2;

debugger;

Now, it either works or stops working for completely unknown reasons, literally. It can be few lines of code and it still ignores break points. It seems that Adobe Script Runner by renderTom sometimes works, but also – just sometimes.

While it most likely results as a conflict with OS and nothing directly related with code itself (because it can appear on any simple code), anyone else have hard time with it? Even on windows, on more complex projects, debugger quite often stops working. Then you either restart the debugger, or restart Code & After Effects to make it work to initialize the target.

[Tomas Bumbulevičius]

Andrei – thanks a lot for your response. Thats exactly what I tried in the first place – but it appeared to be that eval([string variable that is read from a file line by line]) doesn’t return anything. That is why I tried toSource back and forth to just see whats happening there. Any ideas why eval might not work?

I found out that adding parentheses to eval actually works:

eval(‘(‘ + a + ‘)’)

On the other hand, I found a different way to turn string into object, which works.

var b = (new Function( “return ” + a ) )() ;

But be aware if anyone uses, that its also injecting the code / not safe method, as well as eval.

Last but not least, is there a better way to read files into string, than readln in a while eof loop? As I see that with 1MB+ files its slow as well.

Cheers!

[Tomas Bumbulevičius]

Hey Andrei, thanks a lot for your in-depth responses. I tried it in multiple ways but received same results, thus will break it down real quick in case I miss something.

1. I have .json file on a disk. I read it line-by-line as a plain string into memory, into variable A.
2. Then turn variable A into variable B as A.toSource(). It makes whole text into a an object of “New String” – I guess thats what toSource is expected to do.
3. Presumably, evaluating variable B into variable C should get an object from strings, right? as var C = eval(B). What it actually returns is back to the same A string, without making it an object.

Now I found different topics where extra brackets are suggested as eval(‘(‘ + B + ‘)’) is executed, but it didn’t made a difference.

I made the same approach from file as well as object written as string to variable (to make sure there is no read from file issues) but result remained the same – toSource string eval’ed became the same string.

It might be that I am not understanding the concept properly and result is exactly as it should be – that way, any chance you could point to the resources I could look at? Thanks!

P.S. Filip I am looking to implement json parsing through extendscript solely, but thanks for a suggestion expression-wise!

[Tomas Bumbulevičius]

Hey Andrei, thanks a lot for your response. I am aware of eval’s safety issues, that it can evaluate malware functions added as objects.

On a different note, what you say makes total sense when data is already available on hand. But what about when its read from file? Should it be opened and scanned line-by-line intro string, to be able to source it? Or what would be approach in such external file case?

I will test it myself, but curious what do you think. Thanks as always!

[Tomas Bumbulevičius]

Hey Andrei, thanks a lot for your insight! As I am not aware of this method, could you please elaborate further on this, whether:
a) JSON file structure itself needs to be appended with toSource()?
b) JSON file should be read as string and then appended and evaled?
c) Anything else?

Thanks, A!

[Tomas Bumbulevičius]

Thanks, Dan! I tried a similar approach and then it resulted in the same way – not updating properly. Thus I tried to, instead, calculate it “elsewhere” in a slider presuming it might become calculated somewhat “earlier” in grand scheme of things. Not working either, though ! But I will keep on digging it, as its an interesting case 🙂