Posts in Category "samples"

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 Paths: The Basics

In my previous blog post, I presented a fairly complete extension panel for InDesign. This time, I’d like to step back a bit and talk about the process of developing an extension for three Creative Suite applications: Illustrator, InDesign, and Photoshop. We’ll be doing something pretty basic–drawing the same shape in all three applications. While we’re at it, we’ll create a framework we can use to draw any valid shape­. This framework will simplify and standardize the process of drawing a shape, and will work for almost any extension that needs to draw shapes.

In this example, we’ll create a generic extension that can run in any of the above applications, and we’ll keep our application specific code isolated from the overall workings of the extension.

It’s All in the (Application-Specific) Details

The trickiest part of this extension, in fact, is the application-specific code. Illustrator, InDesign, and Photoshop can all draw paths, but each of the applications has a slightly different way of performing the task. In all three applications, you can draw paths using the Pen tool, and the resulting shapes, from a scripting point of view, are made up of paths, which are, in turn, made up of path points. The names and the details of the scripting objects differ a bit between products. In Illustrator and Photoshop, for example, the basic drawing object is a pathItem; in InDesign, it’s a pageItem.

Next, the applications have different ways of dealing with measurement. We’ll need to use measurement values to specify horizontal and vertical coordinates if we’re going to position new path points in a document. In InDesign and Photoshop, you can change measurement units at any time; Illustrator, by contrast, always uses points when it’s being driven by a script. In this example, we’ll be using points, but, for your own scripts, you’ll need to convert measurement values to points before sending them to Illustrator.

In InDesign and Photoshop, path point coordinates are specified relative to the ruler zero point; in Illustrator, they’re specified relative to the lower-left corner of the artboard. Since the default location of the ruler zero point is the upper-left corner of the document in all three applications, this means that the paths in Illustrator will be upside down relative to the paths in the other programs, but we don’t need to worry about that right now.

Finally, Illustrator and InDesign have a number of “shortcuts” for drawing paths with specifc arrangements of points–rectangles, ellipses, regular polygons, etc. We’ll ignore those features in favor of a “one size fits all” drawing routine.

In this tutorial, I’ll present support routines that provide a consistent approach to drawing paths in these applications. The idea is to create a generic drawing function that you can use to build new creative effects (ornamental borders for certificates, for example) or wire into your new data driven graphics feature.

You can download the project here (note that this isn’t really a “finished” extension, it’s just a container for the drawing routines):

drawing
Continue reading…

MakeSideHeads: A Complete InDesign CS5 Panel

The MakeSideHeads example (download link below) shows how to create a fully functional InDesign CS5 panel using the Creative Suite Extension Builder and the CSAW and host adapter libraries for InDesign.

This extension demonstrates:

  • How to use CSXS events and event listeners.
  • How to use the host adapter library for InDesign to monitor and respond to application-specific events (i.e., events that are outside of the standard CXSX events)
  • How to work with InDesign’s find text preferences from ActionScript
  • Reading and writing CSXS preferences
  • How to display a modal dialog box from a CS Extension
  • A number of InDesign scripting tricks

Download a Zip archive containing the project here:
makesideheads

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

Continue reading…

Drag and Drop in a Creative Suite Extension

One of the great benefits of working with the Flash/AIR environment, inside the Creative Suite, is how easy it makes tasks which would be significant challenges in C++. The geolocation sample is one example of this, but another is drag and drop.

This is something with a lot of potential benefit for developers, but (due to some limitations with the current environment) needs to be addressed in a specific way. To achieve this, we use the Flash NativeDragManager, triggered on a mouseDown listener added to our component like so:

<mx:FileSystemTree
id="fileSystemTree"
width="80%"
height="80%"
mouseDown="onFSTreeMouseDown(event)"
/>

We can then implement this listener to begin the drag:

public function handlePureFlashFileDragStart(event:Event):void
{
var clip:Clipboard = new Clipboard();
clip.setData(ClipboardFormats.FILE_LIST_FORMAT, event.currentTarget.selectedItems);

var allowedActions:NativeDragOptions = new NativeDragOptions();
allowedActions.allowLink = false;

NativeDragManager.doDrag(event.currentTarget as InteractiveObject, clip);
}

Here, we have the option of what kind of data we load onto the clipboard (in this case it is a collection of files), and also, if we so desire, we can add an Image object which would be used as the thumbnail for transfer.

If you’d like to see this in action, we’ve created a project which allows files to be dragged from a filesystem tree view into InDesign. It also allows text to be dragged from InDesign to a box in the extension, and back, using the same mechanisms. You can find that here.

For more information on Flash native drag and drop, you might like to look at the tutorial on the Adobe Developer Connection and the livedocs for the NativeDragManager.

Creative Suite Developer Summit 2010 – Conference Recordings

A few weeks back, we gave presentations to a Creative Suite developer summit in Seattle, quite a few of which were focused partly or exclusively on using Creative Suite Extension Builder and the Creative Suite SDK.

Find below some Connect recordings from the conference with content relating to Creative Suite SDK / Extension Builder.

Introduction To Adobe Creative Suite SDK http://my.adobe.acrobat.com/p71668025/ In this session we outline the “why” and provide an introduction to CS SDK programming with CS Extension Builder. Creating, running and debugging a basic CS5 extension.
Developer Summit Keynote http://my.adobe.acrobat.com/p86889547/ Bill Hensler, the VP and Chief Technologist for Adobe’s Creative and Interactive Solutions business unit, addresses the conference. As part of this, we demo some CS5 extensions built using Extension Builder and CS SDK.
Connecting the Creative Suite to Web Services http://my.adobe.acrobat.com/p54113401/ Explains why and how you’d integrate Creative Suite with web services and provides examples of integrating with cloud services such as Flickr and Google Maps, and how to use XMP and other metadata to drive the service interaction.
Integrating Creative Suite With Other Systems http://my.adobe.acrobat.com/p88566846/ Discusses how CS Extension Builder enables integration with other systems such as Adobe LiveCycle Data Services, Adobe LiveCycle Enterprise Suite and Adobe InDesign Server. Shows an example integrating LiveCycle Data Services with the Creative Suite, using CS Extension Builder and the Flex messaging API, and an integration of InDesign Server with Creative Suite point products and LiveCycle Enterprise Suite.
CS SDK Advanced Development Part 1 http://my.adobe.acrobat.com/p33534678/ Covers topics such as debugging, capabilities in the manifest, styles/skinning/ theming, signing and packaging, enterprise deployment.
Advanced CS SDK  Development Part 2 http://my.adobe.acrobat.com/p21181040/ Covers topics such as using the AIR 2.0 APIs (such as NativeProcess, ServerSocket and others) from a CS5 extension, persistence mechanisms such as SharedObject / CSXSPreferences, SQLite, FlexORM and localisation in both the bundle manifest and the SWF application.
Bridge Extensions and Inter-application Communication http://my.adobe.acrobat.com/p33908050/ How to use AIR 2.0 APIs to build CS5 extensions capable of inter-application communication, showing advanced examples of communicating between Bridge and Photoshop with this mechanism.
Application and Technology Specific Programming with the CS SDK http://my.adobe.acrobat.com/p18301218/ Tips and tricks and practical advice on working with the different applications in Creative Suite CS5 and the nuances of targeting each application. Although the Creative Suite SDK goal is a unified extensibility story across CS applications, this presentation discusses the lay of the land and introduces app-specific tools, as well as the Host Adapter micro-SDK, and CSAWIDExporter, a tool for generating InDesign/InCopy ActionScript wrappers exactly matching the app DOM at point of generation.
Converting your existing Flex, ExtendScript, & C++ to the CS SDK http://my.adobe.acrobat.com/p82252880/ Pointers on converting code to the Creative Suite SDK, showing how you can convert or leverage existing ExtendScript code, things to watch out for when taking existing Flex/AIR code over to Creative Suite SDK, and tips on converting C++ plugin code to use Creative Suite SDK, and the whys and hows of hybrid extensions.

Leveraging C/C++ libraries in the CS SDK using Alchemy

This post is going to walk through creating a CS Extension which checks grammar in InDesign. To achieve this, we’ll be using an Adobe Labs technology called Alchemy. If you’re not familiar, Alchemy is a tool that lets you compile C/C++ code into ActionScript bytecode. That means you can efficiently call into your C/C++ code from a pure ActionScript solution. This is especially exciting in the context of the Creative Suite because many developers already have a huge amount of existing code in C/C++. Here’s a brief demo:

 

 

Getting up and running with Alchemy

The following links should be enough to get you going:

Defining the interface

After Alchemy is set up, we next need to download an open-source C library called Link Grammar, you can get the source from here. While the library has plenty of features, we’ll just be using it to tell whether a sentence is grammatically correct or not. To call into this C library from ActionScript we need to define an interface that Alchemy can understand. We define this interface in the C code’s main function. Link Grammar defines a sample main in src/parse.c; replace it with this one, which defines the interface to Alchemy. Here are some magical lines to note:

AS3_Val setupFunction = AS3_Function( NULL, setup );
AS3_Val isThisGrammarFunction = AS3_Function( NULL, isThisGrammar );
AS3_Val result = AS3_Object( “setup: AS3ValType, isThisGrammar:AS3ValType”,

setupFunction, isThisGrammarFunction);

AS3_Release( setupFunction );
AS3_Release( isThisGrammarFunction );
AS3_LibInit( result );

 

This tells Alchemy that we have two C functions we want to expose to ActionScript; setup and isThisGrammar. Now all we have to do is flesh out these functions. For example, here’s our isThisGrammar function:

static AS3_Val isThisGrammar(void* self, AS3_Val args) {

Sentence sent;
int num_linkages;
char* val = NULL;
AS3_ArrayValue( args, “StrType”, &val );
sent = sentence_create(val, dict);
num_linkages = sentence_parse(sent, opts);
if (num_linkages > 0) {

sentence_delete(sent);
return AS3_True();

}
sentence_delete(sent);
return AS3_False();

}

 

This function first reads in a string passed from ActionScript and stores it in the variable val. We then pass val into the Link Grammar library. Based on the result, we return a Boolean to ActionScript telling it whether or not this sentence is grammatically correct. Notice, because we’re in C-land we have to keep in mind memory management (e.g. releasing the sentences when we’re done).

 

Compiling the library

Now that our interface is defined, let’s compile the C code into a swc. Since Alchemy uses a modified version of gcc, we pass it the compiler flag “-swc”. In the Link Grammar Makefile, we need only to change the rule which builds the binary so that it reads:

 

${BIN}/parse: ${OBJECTS}

${CC} ${CLDFLAGS} ${OBJECTS} -swc -o parse.swc

 

Running “make” from the command line will generate parse.swc. Easy as that!

 

From the ActionScript side

In most Alchemy use cases, all we have to do is initialize the C library and then call into the interfaces we defined:

var loader:CLibInit = new CLibInit();
var lib:Object = loader.init();
lib.setup();

 

However, it’s slightly more complex in our case. Alchemy requires that you pass any files needed by the C code as a byte array to the loader before calling your interfaces. Because the C code requires access to the file system (to read the dictionary, grammar rules, etc.), we’re going to need a function something like this:

private function supplyFile( loader:CLibInit, file:File, fileName:String):void {

var bytes:ByteArray = new ByteArray();
var stream:FileStream = new FileStream();
stream.open(file, FileMode.READ);
stream.readBytes(bytes, 0, stream.bytesAvailable);
stream.close();
loader.supplyFile(fileName, bytes);

}

 

And that’s all there is to it. To compile the CS Extension, generate the swc and copy it into the libs/ folder. At runtime, make sure you have the contents of Link Grammar’s data/ folder (which includes 4.0.dict, words/, etc.) copied onto the desktop.

 

 

Attached Files:

Localizing Adobe Creative Suite 5 Extensions

If you are developing extensions for Creative Suite CS5, you might want to adapt your software to your audience based on their language or specific region. The Creative Suite host applications have been localised to many languages and now you can also localise your extensions so your users will be able to interact with them in their native or preferred language.
Adding multiple locale support doesn’t have to increase your engineering effort. This cookbook recipe explains you how you can localise not only your extension user interface but also the extension configuration.
There is also a sample that puts in practice the steps explained in the cookbook recipe. This image below shows how the same extension can be localised to different languages and also how we can change it’s configuration based on specific locales. The same sample extension is running in an English version of Illustrator, a Japanese version of Flash Pro and a Spanish version of Photoshop.
localised_extension.jpg
If you are using Extension Builder, you can download the “Localised” sample by selecting:
File > Import > Other > Adobe Creative Suite Extension Builder > Remote Creative Suite SDK Samples > Localised

Geolocation inside the Creative Suite

As part of the Creative Suite Developer Summit we’ve been showing off some sample code that illustrates just how easy certain workflows become when you move into Flash. One of these, that was shown at the session on Connecting the Creative Suite to Web Services (go here to watch), illustrates how you can connect up the Creative Suite to Google Maps and Flickr.

This sample shows an extension built to run in Photoshop, InDesign and Bridge CS5 (and could easily be extended to any product in the Suite). It connects to Google Maps to show location information, and Flickr to show relevant images – with the data used to power those searches customised based on the application the extension runs in. So, in Photoshop this will check the geolocation of the current image (extracted via XMP) and show the images taken nearby. In InDesign it will instead take the location from the machine’s IP address and search based on keywords using the user’s last sentence. Bridge provides a combination of both, where location comes from the XMP and the keywords come from the image tags.

The best part of this is how cheap integration is with these external systems. Google Maps Flex SDK, for example, requires a single MXML entry to create a map, with an additional call into that object being enough to change the positioning of the map;

<maps:Map xmlns:maps=”com.google.maps.*”
    id=”map” width=”263″ height=”229″
    url=”http://code.google.com/apis/maps/”
    key=”SUPER_SECRET_API_KEY”
    x=”30″ y=”10″/>

this.map.setCenter(location,15, MapType.NORMAL_MAP_TYPE);

For Flickr there are plenty of SDK options available, including one for ActionScript, but for the purposes of this I’ve chosen to roll my own calls. This uses a network communications library provided with Extension Builder, which lets us use the minimal amount of code to make a quick call across the network to retrieve the relevant data;

var request:HttpRequest = new HttpRequest(HttpRequest.GET, “http://api.flickr.com”, “/services/rest/”);
request.setParam(“method”, “flickr.photos.search”);
request.setParam(“api_key”, FLICKR_KEY);
request.setParam(“lat”, latLon.lat());
request.setParam(“lon”, latLon.lng());
request.perform(function(response:HttpResponse):void
{
    if (response.succeeded() || response.get_Status() == 0)
    {
        if (response.isParseable())
        {
            // success: XML or JSON response
            var xml:XML = new XML(response.getBodyText());
            for each (var photo:XML in xml.photos.photo) {
            }
        }
    }
});

If you’d like to try this out, you can grab the Extension Builder project here. You’ll need to drop the Google Maps Flex SWC (available here) into the libs folder, and enter your own API key for both the Maps service and Flickr.

I’ve also made it available as a ZXP (here), and as a zip for Bridge (here) the contents of which should be unzipped into your Bridge CS5 user startup scripts folder.