Posts tagged "cs extension builder"

CS Extension Builder 1.5. trial is now live

All,

A fully functional trial version of Adobe Creative Suite Extension Builder 1.5 is now available on Adobe.com. This is the first of our efforts to make CS Extension Builder widely accessible for the entire developer community. The trial will expire on November 1,2011. If at any point during the trial, you would like to get full access to the software and developer support cases, you can purchase a membership to the Adobe Enterprise Developer Program (AEDP).

Click here to download the trial

 
Useful resources

CS Extension Builder Trial FAQ

What’s new in CS Extension Builder 1.5

Create your first extension in under 5 minutes (vid)


gabriel tavridis
Product Manager
@gtavridis

London Flex User Group: CS Extension Builder demo on May 24th,2011 @ 7pm

All,

The CS Extension Builder product team will be in London on Tuesday May 24th, 2011 (@ 7pm) to present at the local Flex User Group. We will demo CS Extension Builder, show examples of what developers have built with the tool, talk about  CS extensibility and show some cool future things we are working on. If you are interested to find out how to create panels for the CS applications, influence the next versions of the product or meet with members of the team, do join us! (no registration is required)

To get more info about the event (venue etc) check the Flex User Group’s meetup website.

 

gabriel tavridis
Product Manager, Developer Technologies
twitter: @gtavridis

CS Extension Builder 1.5 and CS SDK 1.5 are now available

I am very pleased to announce that the latest versions (1.5) of Creative Suite Extension Builder and the Creative Suite SDK are now available through the downloads section on the CS Extension Builder website.

The team has applied significant effort to deliver a release only 12 months after the 1.0 release and we believe that it will be as successful as the first one. Some of the highlights of the 1.5 release are:

  • improved support for hybrid extensions
  • ability to develop for multiple versions of the Creative Suite
  • advanced tools for developing with XMP metadata
  • support for Content Management Systems that support the CMIS (Content Management Interoperability Services) specification
  • extension profiling

To find out more about the 1.5 release, take a look at the articles that the team has published on the CS Extension Builder page. Over the next  few weeks we will be pushing more content (tutorials, articles, videos) to this page and we intend to make it the main resource center for Creative Suite developers. As always your feedback is important.

We hope you enjoy it!

The Adobe Developer Technologies Team

Working with Layers

Layers, in graphic arts programs, give you a way of organizing objects in your documents and controlling their front-to-back stacking order. Illustrator, InDesign, and Photoshop all have layers, and share most basic layer features: you can create, move, hide, and show layers, and you can assign objects to layers. Illustrator and Photoshop have the ability to create layers within layers—“layer sets” or “layer groups.”

As is usual, the scripting model differs among the applications, so I’ll provide a set of wrapper functions that will take the same parameters, regardless of the host application. I’ll put all of the application-specific details inside these functions. I’ll make the functions work for Photoshop layer groups and Illustrator sub-layers, as well as for InDesign’s simpler layers. I don’t want to rebuild each application’s Layers panels, so I’ll provide simple buttons for putting the layer functions through their paces. (It seems to me unlikely that you’ll want to re-create the Layers panel, and more likely that you’ll want to add/assign/move layers without displaying a user interface at all. If I’m dead wrong, please let me know!)

This example is even more basic than the previous one—but I found a number of points that might trip up developers trying to work with layers in their extensions.

You can find the example project here:

layers
Continue reading…

More Basics: Importing and Exporting Files

One of my co-workers (let’s call him “Zak”) recently referred to this series of blog postings as “an expanded Hello World.” Zak wasn’t being critical; he thinks this is a good thing, and I agree. The point is to get developers past the “what do I do now?” hump—the one that follows immediately after you’ve set up your development environment and worked through your first (usually trivial) tutorial example extension.

What I’m trying to do is make sure that new developers don’t get stuck because of some application-specific peculiarity of one of the Creative Suite applications. I know that this can happen, because it’s happened to me. Often.

In this post, we’ll turn back to the “Big Three” applications of the Creative Suite: Illustrator, InDesign, and Photoshop. All three applications can import, or “place” documents, and can export or save files in a wide variety of file formats. Each program has an idiosyncratic way of doing this basic task, so I’ll create a generic wrapper function and encapsulate (hide) all of the application-specific details.

This post follows in the footsteps of earlier posts, notably ”Drawing Paths,” ”Entering and Formatting Text,” and ”Watching the Detections,” and continues to build our basic Creative Suite SDK construction kit.

You can find the project for this example here:
importexport
Continue reading…

Formatting Text Ranges in Photoshop

In response to an earlier post, “Entering and Formatting Text” (here) a couple of folks asked if there was a way to apply formatting to ranges of text in a Photoshop text layer. It’s certainly not obvious from the Photoshop scripting object model how one would go about doing this—in fact, I don’t think it’s possible, and said so in my response to the comments.

This exchange got me thinking. So it’s impossible—how do you do it? I knew that Photoshop has another way of scripting (in addition to the object model), the Action Manager. I made a mental note to pursue this course, and promptly got distracted by other work.

In the comments section of the earlier post, Jeremy Knudsen kindly posted a pointer to an exchange from the (excellent) PS-Scripts forum, in which (excellent) Photoshop scripter xbytor described a way to work with text ranges in Photoshop. xbytor’s (excellent) xtools Photoshop scripting package for ExtendScript looked like it might solve the problem. I considered asking xbytor for permission to port the package to ActionScript, but decided to try solving the problem myself. There’s a lot of code in the xTools package, and I was looking for a lighter-weight solution.

This led me back to Photoshop, the Action Manager, and the Script Listener plug-in.

You can find the example project here.

Continue reading…

Putting It All Together: Path Effects

In these blog posts, I’m trying to create a series of “building blocks” that CS SDK users can put together to make CS Extensions. Need to draw things with your CS Extension? You can pull drawing routines from the “Drawing Paths: The Basics” post. Want to have your CS Extension respond to document open/close events? Grab the DocumentWatcher class from the “Watching the Detections” post.

At the same time, I’m thinking that some CS SDK users are coming to the Creative Suite without deep knowledge of at least some of the applications. A developer who has spent years working with Flash might not know (or want to know) the finer details of drawing paths in Illustrator, or setting type in InDesign.

My goal is to make it possible for these developers to get things done in Illustrator, InDesign, and Photoshop relatively quickly, without having to learn the document object model of each application (each one different). To that end, I’ve provided functions that encapsulate some of the complexity inside applications-specific functions.

Sadly, for this post, we’ll have to leave Photoshop behind, as that application doesn’t really provide a way to tell if a path is selected. (Or, I should say, it doesn’t provide an obvious way—I’m still looking.)

To see how this might work for you, let’s put together a new CS Extension using parts and pieces from my earlier blog posts. We’ll create an extension that applies various effects to the paths of page items selected in the host application, and we’ll get most of the code from the Drawing and DocumentWatcher projects.

This project also gives me a chance to make a point about Creative Suite Extensions in general: I think that we developers often think only in terms of productivity tools—writing XMP metadata or setting up defaults for a workgroup, that sort of thing. We tend to forget that automation can be used to add creative tools and new artistic effects.

The project for this example is here:

PathEffects
Continue reading…

Watching the Detections

Most of the time, Creative Suite extension panels will need to know something about the state of their host application. If the extension, for example, displays a pop-up menu containing a list of the layers in the current document, the extension will need to know when the document closes, or when a new document opens. When the extension detects that the current document has changed, it can do whatever it needs to do to repopulate the menu.

While you could monitor the state of the application using polling—a function in a timing loop that checks the state of the application every so often—it’s much better to use event listeners. Event listeners are triggered whenever a particular event takes place, and run a function that responds to that event in some way. The only trick is that the application you’re interested in working with has to provide some sort of notification that something has happened that’s relevant to your extension. As you’ll see, that’s not always as straightforward as it sounds.

Because CS extensions are built on top of CSXS (Adobe’s Creative Suite Extensible Services framework), they can make use of CSXS “standardized” events.

Event Name Event Triggers:
documentAfterActivate When you activate the document.
documentAfterDeactivate When you deactivate the document
 (i.e., when you bring another document to the front).
applicationBeforeQuit When you quit the application.
applicationActivate When you activate the application.
documentAfterSave Immediately after you save the document.
 

 

Not all Creative Suite applications support the full range of CSXS “standardized” events, but the applications I want to work with—Illustrator, InDesign, and Photoshop—all support the events I’m most interested in. These applications also support other events—later in this post, I’ll show you how to create event listeners for those application-specific events.

We’ll also use two other CSXS events: StateChangeEvent.WINDOW_OPEN and StateChangeEvent.WINDOW_SHOW. These events are not part of the ”standardized” CSXS events—they apply to the state of the panel window itself. For more on general CSXS events, refer to the “com.adobe.csxs.events” section of the CSXS Library API Reference.

To test our event listeners, we’ll get and display the layers in the current document, and we’ll update the list of layers every time a document changes. I’m thinking that this is something that many CS extension developers will want to do.

You can find the project at:

DocumentWatcher
Continue reading…

Entering and Formatting Text

In my previous posts, I’ve shown how to draw objects in Illustrator, InDesign, and Photoshop. The idea was to create generic functions that “wrap” the application-specific code. Each function takes a set of coordinate locations, and uses those coordinates to draw a path. You don’t need to know the details of the application objects properties, and methods needed to draw the path—just send an array to the function, and the function will take care of drawing the path. The resulting paths will be as close to identical as we can make them, given the differences between the applications.

In this blog post, I’ll try to do the same thing for text. I’ll introduce a set of functions for entering text and doing some minor typesetting tasks in Illustrator, InDesign, and Photoshop. Send the function a string of text, a location (as a coordinate pair), a point size, and a font name, and the application-specific code in each “flavor” of the function will take care of creating and formatting the text. Again, I’ll try to have all three applications produce the same result.

While we’re at it, I’ll show how to get a list of fonts from the application and display the font names in a a ComboBox control in the example plug-in. Think of it as a bonus.

The example extension will create a sample document and position the text at the center of the document, but you can use the example makeText functions to draw text wherever you want.

You can find the example project for this post here:

text

Update: This project is now available via Import>Adobe Creative Suite Extension Builder>Remote Creative Suite SDK examples.

Continue reading…

Drawing: Assumptions, Mistakes, and Solutions

My most recent blog post on drawing paths in Illustrator, InDesign, and Photoshop (here) was an interesting exercise for me. In the process of writing the drawing routines, I made several mistakes, found that things I assumed to be true were, in fact, false.

I’ve solved the various problems and have created a workaround or two. I thought it might be useful for other CS Extension developers if I documented the problems and solutions. This way, you can learn from my mistakes. I make lots of mistakes, so it would be nice if we could get some use out of them.

In this article, I’ll show solutions for some of the problems I left unresolved in the previous post. For the most part, they weren’t critical to the point of the post, but it’s nice to tie up the loose ends. I’ve posted an updated version of the project here (this contains all of the code changes discussed in this post):

drawing

Update: This project is now available via Import>Adobe Creative Suite Extension Builder>Remote Creative Suite SDK examples.

My Point of View

First, let me admit to a bias: In my opinion, everything an application can do should be scriptable. Everything. I think InDesign has the best scripting support of the three applications, because its coverage is the most complete. This isn’t to say that it’s perfect, just that it’s a lot closer to my ideal. This means that I tend to approach the other applications with an InDesign bias.

Next, I’m coming to CS Extensions from the world of ExtendScript. My instinct is to develop and debug using the ExtendScript Toolkit (ESTK), then port to ActionScript. I think that this approach is probably shared by quite a few CS Extension developers.

Continue reading…