I am reaching out to understand why UXP (the new plugin framework) does not expose a direct API to trigger and run existing ExtendScript (.jsx) files. In CEP (Common Extensibility Platform), we had the ability to use evalScript to run ExtendScript code within the same workflow. This offered immense flexibility and allowed us to leverage the full power of Photoshop scripting alongside UXP’s new features. However, with UXP, this functionality seems to be completely missing, and I am left wondering:
Why doesn’t UXP allow us to run legacy .jsx scripts directly from the plugin?
Why isn’t there an official way to trigger scripts that are already installed in Photoshop (e.g., in the Scripts folder) via UXP?
Is there a specific limitation or future roadmap that prevents UXP from including a function like evalScript?
The ability to run scripts and control Photoshop deeply was one of the core strengths of CEP. By removing this functionality, we’ve lost a lot of power in terms of automation, scripting, and control. Why has this shift happened?
It feels like UXP is limiting creative professionals and developers by restricting this functionality. I strongly believe that reintroducing a similar flexible, scriptable interface would greatly benefit all developers building in the Photoshop ecosystem.
It is more of a political decision than a technical one. UXP should replace ExtendScript at some distant point in the future. But if you would allow both of them to be mixed together, ExtendScript would stay there forever. And developers would not migrate.
Also, UXP is permission-based and has somewhat improved security. But if you would mix it with ExtendScript, then not much changes.
Thanks for your reply Jarda,
It’s funny that we can’t even access basic functionality like effective visual font size calculation based on boundsNoEffects vs a clean text layer width. in UXP, while also being told UXP should replace ExtendScript. It’s a little ironic that something as simple as maintaining visual consistency between transformed text layers is so unreliable in UXP, especially with something as fundamental as bounds. Makes you wonder, right?
Both UXP DOM and ExtendScript DOM are using Action Manager code under the hood. Same as when you record action in action panel. And AM works same in ExtendScript and UXP with some exceptions where Adobe decided to disable some of them UXP (like action that would quit Photoshop is disabled in UXP for 3rd party).
So if there are differences it must be related to how AM code is used in DOM. I helped to write some parts of UXP DOM and fixed what I could when I had contract. And @DavideBarranca also worked on the same. And there is so much more that could be added into DOM. But that is not something I could decide.
I have difficulty to understand your text issues in your other post. Maybe some images with examples would help? If DOM is broken I think it should be fixed… but not sure when it would be fixed.
Font layers have “size” and then they have “impliedFontSize” and when you scale object one stays the same and the other one changes.
Thank you so much for your response and willingness to help! I really appreciate your time.
To provide a bit more context: I am developing a tool called Kashida Pro, which is aimed at solving one of the biggest challenges in Arabic typography, the application of kashida (Arabic justification/stretching) according to proper Arabic rules. This is a significant improvement over Adobe’s current Middle Eastern Text Engine (Tatweel), and it’s especially useful for Arabic communities.
The tool is working 100% perfectly in CEP (Common Extensibility Platform) as an Illustrator extension. Even if I manually change the text size or scale the text, Kashida applies perfectly without issues.
However, in my UXP Photoshop version, I’ve implemented the same core idea, with adjustments to match UXP’s functionality. The tool works well, but here’s the problem:
When I scale the text or use Free Transform in Photoshop, and then apply Kashida, it starts to collapse or grow uncontrollably. If I manually adjust the font size via the Character panel, it works fine, but this behavior only occurs when scaling or transforming the text.
The same logic works perfectly in ExtendScript (.jsx) without issues, even with scaling, so this is a problem specifically related to UXP and its handling of transformed text layers.
I’ve attached a drive link screen record for the issue of both the UXP tool and the JSX version for comparison. I’d love your insights or any suggestions on how to resolve this issue in UXP.
So I believe the real problem arises due to a limitation in Photoshop’s UXP API, not a flaw in my code. Cuz When I apply Free Transform to a text layer and then use Kashida, the bounds (and the resulting visual width calculation) include the scaled transform, leading to unpredictable behavior, such as the text collapsing or growing too much. This issue does not occur in ExtendScript, as it handles bounds differently, giving a proper separation between the transform and the actual content size.
I think the API does not provide a clear way to differentiate between the visual size of a transformed text layer and its original size, which causes the issue when applying Kashida.
I’m hoping this helps clarify the situation. If I’m wrong please correct me
It’s a little ironic that something as simple as maintaining visual consistency between transformed text layers is so unreliable in UXP, especially with something as fundamental as bounds. Makes you wonder, right?