When will Acrobat support CEP?

[e-spec1]

When will CEP be supported for Acrobat?

[Test Screen Name]

I see about 20 meanings of CEP. Which is yours?

[e-spec1]

 

Common Extensibility Platform (CEP)

The Adobe Common Extensibility Platform (CEP, also known as Panel SDK) is Adobe’s new unified toolset for building enhancements to Creative Cloud applications without the need for C++ or native coding languages. Instead, you get to use familiar web development tools and languages: HTML, CSS, and JavaScript. Incorporate your favorite web development libraries as well.

[Test Screen Name]

Hmm. I have no inside knowledge, but Acrobat has never participated in any of the things the other CC apps are using. I wouldn't hold out a lot of hope.

[lrosenth · Accepted solution]

When CEP can run at the same level of security that Acrobat & Reader require.

[don_ashe]

When CEP can run at the same level of security that Acrobat & Reader require.

This may be a 'correct answer', but it was not a very helpful answer. We still have no idea when to expect CEP support in Acrobat, or if indeed we can expect it at all.

It seems like a specious answer as well. How hard can it be to isolate sensitive parts of the app from the CEP engine? The main thrust of CEP is UI development, anyway. Acrobat already has support for javascript, so obviously that layer has achieved suitable security.

As 3rd party developers, we'd like to have some idea of the future for our products and how they will be affected by the growth of the platform. Does anyone have any idea if this is even on the table for 2019? 2020 maybe?

Thanks!

-Don

[lrosenth]

How about “I wouldn’t hold my breath”? Is that better?

Now, from the other side, can you give us some idea about what type of extension you would like to build for Acrobat that (a) you can’t build today and (b) CEP would help you achieve?

[don_ashe]

Thanks for the quick response! It's certainly more informative, even though disappointing.

The Adobe CEP page still reads:

"The Adobe Common Extensibility Platform (CEP) gives you the power to enhance and extend Adobe CC apps with the standard web stack: HTML, CSS, and JavaScript."

But it doesn't sound like it's even on the radar for Acrobat.

I mainly use extensions to provide advanced workflow automation for companies in a range of industries. I have built ( and maintain ) numerous plug-ins for the CC apps across the entire suite. I can re-use much of the code across all of them, which gives me a more robust and easily maintainable code base, as well as a consistent look and feel across all of the modules.

Except for the apps which don't support CEP, which require a completely different implementation. This increases the cost and efficiency of development for these apps. It also increases my clients' tendency to look at non-Adobe solutions for their PDF needs, which doesn't make my life any easier, either!

So to answer the question, there is nothing I technically can't do in Acrobat without CEP, but it's not necessarily commercially viable at this stage.

HTH,

-Don

[lrosenth]

Yes, but Acrobat isn’t an “Adobe CC app”. It just happens to be bundled with CC, but it’s part of the Document Cloud.

Acrobat has a very different target audience with different requirements, especially in the area of security, that CC does not which (as previously noted) is one key reason we won’t be adopting CEP.

[don_ashe]

Adobe may not call it a CC app, but your customers (and mine) do.  It comes with CC, and it came with CS before there ever was a concept of a Document Cloud. 

     It's hard to believe it 'just happens to be bundled with CC', because its absence would leave a sizable hole in your CC offering. PDF is such an important part of the creative workflow of every company I visit, they will either use Acrobat or another company's tool.

As for the security requirement, that simply doesn't make sense to me. CEP is a completely isolated module,  based on the Chromium Embedded Framework. It has no access to the application DOM or internals that you don't explicitly give it. You already have a scripting layer which, presumably, complies with security requirements, so that becomes the interface you expose to CEP. This compartmentalization ensures that application security would remain intact even with a total compromise of the CEP layer.

Anyway, I really appreciate your insight into the direction of Acrobat development. This does help me make more realistic plans for my own development efforts. As you no doubt recall, the transition to (and then away from) Adobe Dialog Manager was also a bit bumpy, so any insight is good.

Thanks!

-Don

[lrosenth]

Acrobat predates CS…(and almost all of the members of the suite, except Illustrator). And I agree, we would never remove it from CC – but that doesn’t necessary mean that it is targeting the same customer base.

CEP != CEF. It is, in simplest terms, a superset of CEF that deeply integrates with the CC infrastructure in a number of ways – ways that are not secure for the same definition required by Acrobat.

Yes, Acrobat has a very secure scripting layer – that it is in complete control over…which is not the same thing as the one running inside of CEP. (simply having two separate JS execution engines – one in Acrobat and one is CEP – is a HUGE security risk!)

[e-spec1]

So I will rephrase the question; our CEP code uses the XMP SDK to provide the UI to capture custom XMP metadata; either as a palette or in a dialog presented on Save/Save As. This allows us to enforce business rules such as required fields. Acrobat provides a portion of this functionality for standard XMP (but not custom). If we use the Acrobat SDK, does it support the XMP SDK and can our CEP code be easily ported to the older Acrobat environment? We currently support defineg, collecting and usage of custom XMP in the Creative Cloud and AEM; our goal (since Acrobat is prevalent in both clouds) is to also support the Document cloud.

[lrosenth]

Great to focus on a specific use case!

Acrobat still uses the older (CS5) XML-based model for extensible custom XMP panels. I found an old article here (<https://gunar.wordpress.com/2010/05/19/create-custom-metadata-panels-in-cs5-with-xml/>) about them. So if you want to simply be in the XMP dialog itself, that is how you do it.

To deeper integrate, such as a palette or dialog, you will need to write a (completely new) Acrobat plugin (in C/C++) using the Acrobat SDK (which includes access to the XMP SDK). Your CEP code will not be usable.