Skip to main content
nicholash68515175
Known Participant
July 11, 2023
Question

Extendscript Text Casing/Font Problem

  • July 11, 2023
  • 14 replies
  • 1038 views

Hi,

 

We use extendscript to composite thumbnails, and we're finding that there are odd failures where the text randomly has odd casing.

 

We can confirm that the whole Text Area actually has the correct Font and Text Parameters set on it, but for some reason that this could be happening? We're overwriting the text that exists previously, but it's very odd. 

 

If we re-run it again, it won't happen again.

 

 

This topic has been closed for replies.

14 replies

nicholash68515175
Known Participant
July 11, 2023

Awesome, and one last question!

You stated this is a copy and paste operation internally. Right now we're using `sourceText.setValue(textDocument)`. Is this the `copy and paste` operation? 

 

I think this is the only way to set font parameters on a `text` entry - which is important to us. Is there a different method that would avoid this internal copy and paste operation?

 

Thanks for all your hard work Doug! Alongside the clear communications!

Adobe Employee
July 11, 2023

No.

No.

No.

 

It is a bummer - I am sorry.

 

If it feels any better, I wasted a huge amount of time having this happen to me when I was developing the recent Font Server upgrade. Writing a simple script that exercised all the faces of a font (+ variable ones) with the text set to the PostScript name was strangely mixing the applied font up - that is why I know about this.

 

FontLocking is a "good" thing, but not when it is being done incorrectly.

 

Without any ability to find missing glyphs via scripting there is no way to know that something is missing after the "paste", without an API on the Font to ask if all the characters have glyphs, without per-character styling control there is no way to address true missing glyphs in your own away, and there is no control to in the TextDocument to disable FontLocking. All good ideas, eh?

 

All I can offer you at this point is the knowledge that you are not crazy, are not alone, and I am seeing what can be done.

 

Douglas Waterfall

After Effects Engineering

nicholash68515175
Known Participant
July 11, 2023

Wow! I wish I had asked this earlier as we have been wondering about this issue for a very long time.
Is there a workaround in this case for Font Locking? 

 

  • We haven't tested it but would setting the font again AFTER the `copy paste` operation fix this? I think we may have tested this internally but not 100% sure atm
  • As well, is there any scripting method which would allow us to catch these jobs programmatically? I believe `sourceText` will just say it's set correctly, so validating when building the comp won't work...
  • Do you happen to have a rough estimate of a date? 😃😃

 

And yes! It's very difficult to reproduce!! I was honestly surprised that there wasn't more issues open about this....

 

Thanks @Douglas_Waterfall 

Adobe Employee
July 11, 2023

Sigh. It did not change the case, it actually changed the font.

 

This is a known problem (well, I know about it) and has tripped me up in my own development testing.

 

What is happening behind the scenes is named here FontLocking where the code is trying to avoid the missing glyph problem.

 

During the paste operation (that is what Scripting is actually doing) the code takes the characters which are being pasted and asks the applied Font if it has defined glyphs for those character codes. If the Font does not, then the code switches to a fallback Font which will have the glyphs and thus avoiding a blank space/missing glyph.

 

The bug is that the code is often confused and thinks that the glyphs are missing when in fact they are present. This confusion is not deterministic which is why it comes and goes.

 

We are waiting on an integration of new code which we expect to fix this, I have no specific date to offer you.

 

Douglas Waterfall

After Effects Engineering