Rorohiko

What I did in my holidays...

kris@rorohiko.com (Kris Coppieters) — Sat, 11 Jan 2014 14:09:00 -0800

Bumped into this web site:

http://codility.com

It's a web site where they test coders, and every so often, they offer a public challenge you can use to hone your algorithm-design and coding skills.

These are great brain-teasers, and I had tremendous fun solving the challenges - I did the last one of 2013 and the new one of 2014 that was just released.

And I managed to get some badges!

Codility badge

Codility badge

Warning: the challenges are not trivial, and it's one of those 'cannot let it go' things: once you click 'Challenge yourself', you'll find yourself hooked!

Adobe CC. From selling assets to selling consumables.

kris@rorohiko.com (Kris Coppieters) — Mon, 13 May 2013 13:20:00 -0700

Adobe recently made a massive switch: they switched from being a tool vendor to becoming a reseller of consumables. The Adobe CC is treated like a consumable (like electricity, petrol, toilet paper, air travel,...), whereas the Adobe CS was treated like an asset (like a chisel, a car, a house...).

The question on my mind is: if I look at companies selling consumables, how much innovation do I see? How much innovation is for the benefit of the consumer?

If I look at companies selling consumables from a monopoly situation, how much innovation do I see?

It'll be interesting to compare the amount of R&D in asset companies vs consumable companies.

Interesting times ahead!

ExtendScript Toolkit Unbearably Slow?

kris@rorohiko.com (Kris Coppieters) — Sun, 7 Apr 2013 13:07:00 -0700

ExtendScript Toolkit Slowness

Note added 9-May-2017: in addition to the issues outlined below, another, now common, reason for slowness of ESTK on Macs is the 'app nap'. Background apps on Mac 'fall asleep' and become really slow (to save energy). If ESTK is talking to InDesign and InDesign falls asleep, things get really slow. Quickly switching back and forth to InDesign, then back to ESTK wakes them up. On CS6 you can disable App Nap as a 'Get Info' property on the ESTK and InDesign applications in the Finder. For CC and higher, no quick fixes. I have turned off App Nap on ESTK and InDesign CS6, and I use CS6 for script development when I need ESTK.

Recently, I was working on a fairly large script-based solution for Adobe InDesign.
Things progressed well, and the script was growing at a rapid pace.
For small tasks, I tend to write scripts more in a procedural, ad-hoc manner. For more complex tasks, I will normally define some formal object model with object classes, methods, getters, setters, inheritance,...
In this particular case, the system was teetering between the two realms, and it was clear I'd need to go for a formal object-oriented approach some time later, as the complexity started to increase.
But as I was still testing the waters and getting my head around the many aspects of the solution, I had decided not to start on an object model and a class architecture until things had become better defined. Often, with these projects, I go through a ping-pong process with the users and other stakeholders, and valuable information only emerges after a few initial prototypes have been tried out 'in real life'.
Because the script had to serve as a go-between InDesign and an outside system with a wide API (Application Programming Interface), I had a growing collection of symbolic constants, each representing some kind of 'magical' value for the outside system's API.
All was well: the solution grew, and gradually more and more functionality became available; users were impressed.
Speed and responsiveness were great, even when massive amounts of data were being chewed on.
ExtendScript, despite being an interpreted language, is amazingly fast if you know how to treat it correctly.
Until suddenly some unexpected issue came out of the blue: for some reason, ExtendScript Toolkit became unbearably slow.
At first I thought it was one of those unexplicable things that come and go. So I restarted my Mac, reset the preferences, created a brand new user account and tried that way, switched to another Mac. All to no avail.
Simply trying to run the script in ExtendScript Toolkit almost immediately caused the colored pizza to appear and everything ran like molasses.
Running the script straight from the InDesign Scripts palette worked fine. It was only when the ExtendScript Toolkit got involved that things got really slow.
Initially, it was still somewhat bearable. Having to wait a few minutes just to inspect a variable is annoying, but you can grit your teeth and wait it out. But things got out of control very rapidly: a few hours later, the minute-long waits had become half-hour waits.
Run, breakpoint, colored pizza for 30 minutes. Run, breakpoint, colored pizza for 30 minutes...
Ok, this lobster had enough: the water in the pot was becoming too hot, and something had to be done. I started to investigate.
I used the Mac's Activity Monitor to sample the ExtendScript Toolkit process, and found that the ExtendScript toolkit was working very hard. Some poking and prodding revealed that nearly all that hard work was related to the Data Browser element in the ExtendScript Toolkit.
Eventually, I figured out it had to do with the quantity of constants and variables I had created in the global variable space. The Data Browser had trouble displaying all those elements. If I closed the Data Browser, ExtendScript Toolkit's speed became normal.
For what little info I was able to glean from my poking around, I suspect the Data Browser has an extremely inefficient lookup buried somewhere inside its code: it looks like it has many levels of nested linear lookups, and as more elements start populating the global variable space, things get exponentially (or worse than exponentially) slower.
So, I had to refactor my code earlier than expected - and that fixed the issue. The main change was that instead of something like:

const kExternalSys_BoldAttribute = 0x0001;
const kExternalSys_ItalicAttribute = 0x0002;
...

and so on, thousands of those, I made it into:

var kCST =
{
ExternalSys_BoldAttribute: 0x0001,
ExternalSys_ItalicAttribute: 0x0002
...
};
And instead of referring to kWordSys_BoldAttribute, I now referred to kKCST.WordSys_BoldAttribute and so on.
I further reduced the footprint in the global space by making the script fully object oriented, with nearly all functions as methods attached to object classes, rather than having gobs of globally defined functions.
And now it's all fine again!
So, the morale: keep the global variable space as empty as possible, or ExtendScript Toolkit will get ya!

GetURLs.jsx - access HTTP content from InDesign ExtendScript

kris@rorohiko.com (Kris Coppieters) — Wed, 2 Jan 2013 10:49:00 -0800

Note added 9-May-2017: I've revisited GetURL and made a more modern version. More info here:

http://coppieters.nz/?p=133

----

In 2008, I created a sample InDesign ExtendScript called GetURLs.jsx. GetURLs.jsx is a limited http client; it allows you to fetch http URLs straight from an InDesign ExtendScript.
I used the script as sample material to demonstrate a programming technique (state machines).
It turned out the script was quite popular in its own right; I've been adding little tweaks to it over time.
The latest version has been enhanced to handle redirections (when the server returns a status code HTTP 1.0/301 Moved Permanently). Hope it works for you!

The original blog post is here:

http://rorohiko.blogspot.co.nz/2008_07_01_archive.html

and the download link is here:

http://www.rorohiko.com/podcast/geturl.zip

Cheers,

Kris

Fun with Arduino - how to get into assembler programming.

kris@rorohiko.com (Kris Coppieters) — Thu, 6 Dec 2012 01:44:00 -0800

I am having fun with an Arduino Uno. I am old school; I started with a TRS-80 in the late 1970's, did a lot of Z80 assembly language. My computer had a massive memory (for the time) of 16KB, so in order to wring out a bit more, assembler was the way to go.

Gotta say, this Arduino brings back a lot of memories.

I bought a few tutorial kits (e.g. an Arduino Uno), and by the looks of it, the Arduino has a lot of similarities with my first computer, but it's a bit more powerful.

Its clock is 16MHz (my TRS-80 was 1.7MHz).
Its memory is 32KB Flash + 2KB SRAM + 1KB EEPROM (my TRS-80 had 16KB SRAM + 12KB ROM. And cassette tapes for storage)
It uses an 8-bit CPU (so did my TRS-80, which used a Z80).
Turns out that the Arduino IDE uses C++ as its 'main language' (that was Level 2 Basic on my TRS-80).

(And yes, these are KB - Kilobytes. Not Tera, not Giga, not Mega. Kilo. 1KB being 1024 Bytes. I still find it strange how, in 1978, I thought 16KB was unimaginably large, whereas nowadays 16KB in unimaginably small. My MacBook Pro has 8GB SRAM, more than 500,000 times what my TRS-80 had. Wow. That still flabbergasts me.)

The Arduino IDE is cool and all that, but feels kind of wasteful, so I set out on a quest to do some assembler programming on the Arduino.

Turns out that a lot of effort seems to have gone into discouraging doing this. There is a lot of 'magic' going on, and the Arduino IDE hides a lot of complexity from view. With good reason; there is often no need to look beyond the magic. One can opt to just accept it, and it works perfectly fine.

But I like to understand how it all works; dig into the magic, take it apart, and figure out how it works. I've always found that if you understand the magic, you can make better use of it.

I am pretty sure that most of my future Arduino (or Pinguino or Uno32; I bought one each of those too!) exploits will be using mostly, if not exclusively C/C++, but my first experiments are aimed at understanding how to do assembler programming.

I had to do a lot of fishing around to get enough info: lots and lots of little tidbits here and there, but no real 'how to get started' cookbook. So I decided to put the tidbits together in a wee dokuwiki page, and make it as complete as possible, in the hopes that someone else finds it useful.

While searching, often all I am looking for are a few good, complete examples, and that gets me going.

The dokuwiki page below is an attempt to help other people get going, by offering complete, working examples.

I tried to cover all the necessary steps, from patching up your IDE to accept assembly source code down to some increasingly advanced sample assembler programs.

There are some things I've skimmed over (e.g. I assume you know how to set up a Java development environment on your computer).

So, here goes. In case you're looking to get started with Arduino and assembler, here are my 'useful tidbits', for what they're worth:

http://rwf.co/dokuwiki/doku.php?id=smallcpus

If you want more detail for particular things, let me know. If I can find the time, I'll write additional instructions if needed.

Cheers,

Kris

How to Use DropBox More Efficiently

kris@rorohiko.com (Kris Coppieters) — Thu, 29 Dec 2011 00:42:00 -0800

Lately, we've started to use DropBox more and more. Initially, we used it mainly as a tool to keep multiple workstations and laptops synchronized, as well as a means to quickly provide someone a downloadable link to a file without having to fumble about with FTP or WebDAV or other complicated things.

Then we started using the shared folders more and more.

As we nearly always work together with other people and companies scattered all over the globe, DropBox is a godsend: we set up a shared folder, and that's it. Through DropBox, a distributed workgroup can easily share a bunch of files.

But sharing wildly with all kinds of partners created a small problem. How does one keep track of all these shared folders in DropBox. Which is shared with who? Of course, one can go find out via the DropBox web site, but that's not really a quick thing.

So, now we've started to use specific names for the DropBox folders. If a DropBox folder is shared between two parties, we refer to it as a 'tunnel', and we append the name of the two sharing parties.

If we were regularly working together with a company called, say, 'Ynapmoc', I'd use a folder called 'Tunnel_Ynapmoc_Rorohiko' or 'Tunnel_Rorohiko_Ynapmoc'. Often we tend to work on multiple projects with our partners, and we use the tunnel for shuttling shared documents between us.

If a DropBox folder is shared between more than two parties, we would instead create a new folder for each individual project, and simply use the word 'Shared' followed by the name of the project. So, if we were working with, say, three parties on a project called, say, 'Terces', the folder would be called 'Shared_Terces'.

My DropBox folder now looks a lot better organized, and I can tell immediately what each shared folder is meant for.

If you get a request to share a dropbox folder with a name that starts with 'Tunnel_...' you'll know what that means!

Cheers,

Kris

Mac OS X Lion - how to get Unicode back on your Character Viewer.

kris@rorohiko.com (Kris Coppieters) — Tue, 15 Nov 2011 12:00:00 -0800

One handy little tool I use all the time in Mac OS X is the Characters Palette which I can access via the menu bar.

You enable it by going to the System Preferences - Keyboard, and ticking 'Show Keyboard & Character Viewers in menu bar'.

I've upgraded to Lion a wee while back, and had not needed the characters palette - but recently I wanted to have a quick look at some Unicode character codes. I brought up the characters palette via the menu bar:

But the resulting palette seemed to be quite spartan and bare and the familiar Unicode table just was not there.

Turns out: the Unicode table is still there, but you need to turn it on first. Click on the settings button, and select 'Customize List...'.

Then scroll all the way down until you see 'Code Tables'. Click the disclosure triangle and tick the checkbox for Unicode.

That adds the Unicode table back. Great for browsing around in Unicode!

Hope this saves someone some time and frustration!

Cheers,

Kris

Software Distributors

kris@rorohiko.com (Kris Coppieters) — Mon, 11 Jul 2011 19:12:00 -0700

I am puzzled - not sure how to deal with software distributors.

Here at Rorohiko Workflow Resources, we've been hard at work for many years now, to build a whole range of tools, mainly for users of the Adobe Creative Suite. Our range of tools is slowly but steadily increasing.

In order to sell and try to make our investment pay back for itself, we've built an automated software selling system, which works relatively well: we have a peculiar approach to how we sell our software, which allows us to sell our tools at very low cost despite aiming for a limited market. Part of the secret is automation.

E.g. you can purchase an activation for TextExporter for all of US$19.00. This low cost means that purchasing an activation for one of our tools pays back for itself very quickly.

We're gradually getting more and more traction in the market - which is cool.

Now, lately we've been getting more and more requests from software distributors who want to distribute our products - but most of them have the same puzzling approach.

They want to know what their dealer margin is, and where they can send a purchase order.

A few times, we've tried to accommodate such requests, but invariably, we ended up holding the longest end of the stick: working with software distributors invariably costs us more than it's worth.

- They cause a whole lot of additional administration (purchase orders, paper or PDF invoices,...). Such additional admin costs us money.

- They want to send us a purchase order and in return get an invoice. Then they take their own sweet time to pay up.

They often need one or more reminders. Their purchase department is typically insulated from the rest of the company, and once our invoice is in the slow paper mill, it can take six months or longer before we finally get paid, and there is nothing much we can do about it.

- They want to pay us by cheque or credit card, and don't want to use PayPal. As Rorohiko is still small, and establishing credit card facilities would cost us both in time and money, we make do with PayPal.

(We've looked around, and after that exercise, we think that despite a number of obvious shortcomings, PayPal is one of the better payment processors on the market. Through PayPal we can accept credit cards. People with corporate credit cards seem to have a few extra hoops to jump through - but once they set up an address-verified PayPal account, things seem to work fine.)

- They don't seem to have time to read: we have a lot of info on our web site, and, granted, it's not that well organized, but these people clearly have not even visited our web site. They don't know what our products do, and are not interested in learning how our licensing system works (http://www.rorohiko.com/licensing).

In the end, we sell a single $19 activation, and end up with costs that far surpass that amount - paperwork, having to wait to get paid... it all adds up.

As such, we see any such requests from software distributors as a 'win/lose' scenario: they win, we lose.

My question is: are there some software distributors out there who understand the idea of a 'value proposition'? If you're a software distributor, and you like our products: before e-mailing us, make sure you have something of that is of value to offer in return for the extra hassle. There's many ways you could make this work.

Also, reading up on our products and our approach to licensing beforehand gains you brownie points!

Fitting of Images Into Frames in Automated and Semi-Automated Page Layout Workflows

kris@rorohiko.com (Kris Coppieters) — Sat, 9 Apr 2011 18:06:00 -0700

When developing workflows around InDesign Server or similar automated page layout workflows, one of the recurring themes is the fitting of image material into frames on a page.

In this blog post I'll demonstrate a method for efficiently storing re-usable image fitting data. The image fitting data is resistant to image replacement or layout changes in the page layout.

This method can easily be implemented in ExtendScript/JavaScript or any other programming language.

I'll also show a corresponding user interface.

It all starts with an image and a frame. Most commonly, both are rectangular, but their shape is not necessarily related: the image might have a landscape orientation and the layout frame that the image needs to fit in might have a portrait orientation.

What I'll present in this article is (as far as I know) a novel way of encoding image fitting data into four numbers, in such a way that the fitting data becomes totally decoupled from the actual frame and image shapes. The same fitting data can be re-applied to images and frames of wildly different shapes, and always gives sensible results.

The fitting data is fairly straightforward to grasp intuitively - the four numbers I use are called (xFactor, yFactor, scale, rotation).

xFactor and yFactor range between -1.0 and 1.0, scale between 0.0 and 1.0, and rotation = 0, 1, 2 or 3.

xFactor = -1.0 means: frame at the extreme left side of image.

xFactor = 0.0 means: frame horizontally in the middle of the image

xFactor = +1.0 means: frame at the extreme right side of the image.

yFactor = -1.0 means: frame at the extreme top side of image.

yFactor = 0.0 means: frame vertically in the middle of the image

yFactor = +1.0 means: frame at the extreme bottom side of the image.

scale = 1.0 means: frame as large as possible without going 'outside' the image

scale = 0.0 means: frame infinitely small

rotation = 0: image not rotated

rotation = 1: image rotated 90 degrees

rotation = 2: image rotated 180 degrees

rotation = 3: image rotated 270 degrees

Below are a few intuitive samples.

Keep in mind: in the samples below I'm continually using different images and/or frames - the main 'claim to fame' of the decoupled image fitting data is that no matter what image or frame shapes you throw at it, it always gives sensible results.

First two samples, both using the exact same fitting data - xFactor = 0.0, yFactor = 0.0, scale = 1.0, rotation = 0.

As you can see (0.0, 0.0, 1.0, 0) translates to: center the frame on the image, and make the frame as large as possible. It does not matter whether the image has portrait or landscape orientation, and it does not matter whether the frame has portrait or landscape orientation - the same fitting data always works.

(0.0, 0.0, 1.0, 0) is the default fitting data I most commonly use for images and frames that have not been edited by a user.

Now a sample image, and a differently shaped frame, this time using (0.0, 0.0, 0.5, 0) as the fitting data: the scale is 0.5 instead of 1.0. The frame shrinks down to half the largest possible size both horizontally and vertically:

Another sample image and frame, now using (-1.0, -1.0, 0.5, 0): the scale is the same as in the previous sample, but now the frame has moved to the top left corner.

Any fitting data with xFactor = -1.0 and yFactor = -1.0 always means: move the frame to the top left corner.

To help understand my image fitting method, think of the frame as a window through which we can see part of the image.

Imagine I float a rectangle in the same shape as the frame on the page 'on top' of the image. I'll combine two actions:

1) Shifting the frame around within the image
2) Resizing the frame so it covers more or less of the image

l'll initially assume the floating frame rectangle is not allowed to go 'outside' the image. It is forced to stay within the confines of the image.

With regards to the positioning of the floating frame: I will be encoding the position of the center of the frame with respect to the center of the image.

For the sake of argument, I'll first only consider the vertical position of the floating frame.

I observe that when the floating frame covers the full height of the image, it has no room to move vertically (otherwise it would escape the confines of the image).

(No vertical leeway: the frame cannot move up or down without leaving the confines of the image)

In essence, the amount of 'vertical leeway' is determined by the difference in height between the floating frame and the image. If the image and floating frame have the same height, the vertical leeway is zero. At the other extreme, if the floating frame height were reduced to zero, the vertical leeway would be the full height of the image.

(Vertical leeway is difference between image height and frame height)

When the floating frame is positioned in the center of the image, I can move it half the vertical leeway towards the top, and half the vertical leeway towards the bottom.

(When the frame is centered on the image we can move half the vertical leeway up, and half the vertical leeway down)

That brings me to one of the key numerical values: given an image and a frame, I calculate half the vertical leeway (in other words: I subtract the frame height from the image height and divide by two).

I then express the vertical position of the frame center with respect to the image center as a value between -1.0 and 1.0. When I multiply this value with half the vertical leeway, I get the frame's center offset along the y-axis in relation to the image center.

I do the same for the horizontal axis: encode the horizontal offset of the frame center from the image center as a value between -1.0 and 1.0. Multiplying this value with half the horizontal leeway gives me the frame center's horizontal offset from the image center.

To encode the frame size, I first rescale the frame so it 'fits' the image in one of the two dimensions. I make the frame as large as possible without 'spilling out' of the image. When I do that, either the horizontal or vertical sizes of image and floating frame will be equal, and in the other dimension the frame size will be less than, or equal to the image size.

I call the 'equal' dimension 'the dominant dimension' - each time someone gives me an image and a frame, I can determine the dominant dimension for that particular (image, frame) pair - it's either horizontal or vertical (and occasionally both - in which case I pick either).

(The vertical dimension is dominant: the frame can be made to fit the image vertically while it remains narrower than the image horizontally)

I now encode the frame scaling as a number between 0.0 and 1.0 along the dominant dimension. If the scale is 1.0 the frame and image have the exact same size along the dominant dimension. If the scale is 0.5, the frame is half the size of the image along the dominant dimension. The non-dominant dimension is resized proportionally.

(scale = 0.5 means that the frame is half of the image size along the dominant dimension)

Finally, I need to encode image rotation: the image can be rotated underneath the frame. I encode that as an integer number from 0 to 3 (0 = not rotated, 1 = 90 degrees... ).

So, to make an image fit into a frame, I have the fitting data encoded as four numbers:

xFactor = -1.0 to 1.0 (floating point)
yFactor = -1.0 to 1.0 (floating point)
scale = 0.0 to 1.0 (floating point)
rotation = 0 to 3 (integer)

I'll now work through a step-by-step procedure of using this fitting data.

Assume I'm given fitting information (a set of four numbers: (xFactor, yFactor, scale, rotation) as well as an image with dimensions (widthImageUnrotated, heightImageUnrotated) and a frame in a page layout with dimensions (widthFrame, heightFrame).

If scale is 0.0, I don't even start the process - it would lead to a division by zero.

First I take into account the rotation. If the rotation is 1 or 3, I need to swap the image width and image height because the image is turned on its side through a quarter turn.

Based on rotation and (widthImageUnrotated, heightImageUnrotated) I define a new pair of rotation-adjusted image dimensions (widthImage, heightImage).

The next step is determining the dominant dimension. I calculate two ratios:

horRatio = widthFrame / widthImage

and

verRatio = heightFrame / heightImage

The larger of these two ratios belongs to the dominant dimension.

For the sake of argument, I'll first assume horRatio ends up to be the larger of the two. That makes the horizontal dimension the dominant one. This means that I can make the frame 'fit' the image horizontally while leaving the vertical frame height less than or at most equal to the image height.

In that case, the scale division factor that I apply to the image, imageScaleDiv, is determined as

imageScaleDiv = scale / horRatio

In the other case, where the verRatio turns out to be the larger of the two instead of horRatio, I would use

imageScaleDiv = scale / verRatio

I rescale the image by dividing the image dimensions by imageScaleDiv, so its new size becomes (widthImageScaled, heightImageScaled):

widthImageScaled = widthImage / imageScaleDiv

and

heightImageScaled = heightImage / imageScaleDiv

Normally, imageScaleDiv should not be zero at this point of the procedure - we don't allow for zero scale values.

I now calculate horizontal and vertical leeways:

horHalfLeeway = (frameWidth - imageScaledWith) / 2.0

and

verHalfLeeway = (frameHeight - imageScaledHeight) / 2.0

Now I multiply these 'half leeways' with the xFactor and yFactor to find the offset of the image center compared to the frame center:

xOffset = xFactor * horHalfLeeway

and

yOffset = yFactor * verHalfLeeway

This concludes the procedure: I've taken a set of four numbers (xFactor, yFactor, scale, rotation), applied them to an image and a frame, and ended up with sufficient scaling information and positioning information to allow me to put the image into the frame.

The power of this encoding becomes apparent when I retain only the fitting information, and apply the same set of four numbers to a completely different image and/or frame: it still works, and in most cases, the 'fit' is 'natural'.

So, if I have a person's portrait in a frame, and swap it for a different portrait, the fit will most probably still be correct - most headshots share the same basic proportions. Here's an example where the two images are very different, yet re-using the same fitting data works well:

(fitting info: (0.0, 0.0, 0.75, 0) )

(fitting info: (0.0, 0.0, 0.75, 0). The same fitting info as the previous image. Even though the image shape is quite different, the same fitting info still works well)

Another advantage is that I can tie the image fitting info to the user interface, and get something that acts rather 'naturally'.

If I position the cropping frame, say, in the top left corner and change the scale, the cropping frame will remain in the top left corner and extend down and to the right.

(fitting info: (-1.0, -1.0, 0.5, 0) )

(fitting info: (-1.0, -1.0, 0.75, 0). Changing the scale from 0.5 to 0.75 keeps the frame 'stuck' in the corner)

If I position the cropping frame dead center and change the scale: it will grow and shrink while remaining centered.

(fitting info: (0.0, 0.0, 0.5, 0) )

(fitting info: (0.0, 0.0, 0.75, 0). Changing the scale from 0.5 to 0.75 keeps the frame 'stuck' in the center)

When an automated or semi-automatic workflow has some image fitting operation in it, storing the image fitting data as a set of four numbers, and applying them as described here increases the chances that the fitting data will continue to give sensible results even when the image is replaced with another, or the frame is resized later on (e.g. when a template is adjusted). The fitting data is fully decoupled from image and frame dimensions.

The method described here also remains usable outside the limitations I originally set out.

By allowing xFactor and yFactor to go outside of the interval [-1.0, 1.0] I can allow for frames that only partially overlap the image.

Similarly, scale factors outside of the interval ] 0.0, 1.0 ] can be used too - I could allow negative scale factors or scale factors larger than 1.0. However, a zero scale factor will never give sensible results - it results in a division by zero.

Finally, the rotation can be allowed to be a floating point number in the interval [0.0, 4.0[ instead of an integer 0 - 3. That way, I can rotate over arbitrary angles - e.g. a rotation of 0.5 would translate into a rotation of the image of 45 degrees.

The screen shots that accompany this blog post demonstrate the related user interface - the screen shots are from an AJAX implementation I made for a real-life project, using Google Web Toolkit (GWT) running in an ordinary web browser.

I found it helpful if I made the scale slider to show the effective image resolutions (instead of the underlying scale factor).

In general it works like this: initially, in an automated setup, I always start with a default fitting of (xFactor, yFactor, scale, rotation) = (0.0, 0.0, 1.0, 0). That centers the frame onto the image, and makes the frame as large as possible, cropping away part of the image if necessary.

When the user edits the image fitting through my user-interface, I store the resulting fitting parameters (xFactor, yFactor, scale, rotation) alongside the layout (e.g. the script labels are a great spot to put this).

When the layout or image changes, I retrieve the fitting data and re-apply the fitting data to the new image or the modified frame.

It works really well for me - hope it does for you too!

(c) 2011 Kris Coppieters - Rorohiko Ltd.

Are Mac users quicker to upgrade to InDesign CS5 than Windows users?

kris@rorohiko.com (Kris Coppieters) — Thu, 31 Mar 2011 15:23:00 -0700

I recently saw some Facebook 'polls' that looked like an attempt to probe who is using what version of InDesign. Oftentimes, these polls fall flat because the sample size is too small.

But if you want to know how the InDesign user base divvies up, at Rorohiko we have fairly significant, up to date information - further down, I'll share with you some usable percentages and graphs for the month of March 2011.

The clue is in our web server logs. We watch downloads of our APID ToolAssistant for InDesign plug-in, and that tells us a lot (http://www.rorohiko.com/apidtoolassistant).

Here's how it works. APID ToolAssistant in itself does not do anything obvious for the end-user, but in order to use one or more of our extensive range of plug-ins, users need to install APID ToolAssistant on their computer. Each user needs to install APID ToolAssistant only once per installed version of InDesign. Every month we get a few hundreds of downloads of APID ToolAssistant.

What makes APID ToolAssistant unique as a market probing mechanism is that we still support versions of InDesign as far back as InDesign CS - we cover the whole range of CS, CS2, CS3, CS4 and CS5.

On top of that, our downloads are separated - instead of one single download, we provide separate downloads for each platform and each version - 10 downloads in total - so we can monitor each platform/version combination separately.

In March 2011, we had 1548 downloads - and these were separated up as shown below.

To paraphrase the graphs below in words: Mac and Windows are about even, about 10% of all users are still using CS and CS2 and about 30% of all users is still on CS3 or below. Finally, CS5 is slightly ahead of CS4.

P.S. If this info is interesting to you, contact consulting@rorohiko.com - there's more where that came from!

Downloads of APID ToolAssistant in March 2011
Mac, CS	41	3%
Mac, CS2	46	3%
Mac, CS3	130	8%
Mac, CS4	236	15%
Mac, CS5	363	23%
Win, CS	42	3%
Win, CS2	51	3%
Win, CS3	135	9%
Win, CS4	257	17%
Win, CS5	247	16%
Total	1548

Downloads of Mac APID ToolAssistant in March 2011
CS	41	5%
CS2	46	6%
CS3	130	16%
CS4	236	29%
CS5	363	44%
Total	816

Downloads of Windows APID ToolAssistant in March 2011
CS	42	6%
CS2	51	7%
CS3	135	18%
CS4	257	35%
CS5	247	34%
Total	732

Downloads of APID ToolAssistant in March 2011
Mac	816	53%
Windows	732	47%
Total	1548

More Efficient Storage of Virtual Machine Backups

kris@rorohiko.com (Kris Coppieters) — Fri, 11 Feb 2011 18:21:00 -0800

Here's a little trick I use to save substantial amounts of disk space.

For testing our software, we heavily rely on virtual machines, mostly running various versions of Windows - we use VMware (both VMware Workstation on PC and VMware Fusion on Mac), Parallels, and VirtualBox extensively.

VirtualBox is my current favorite - it's come a long way since the earlier versions, and to me it's now on a par with VMware and Parallels. Furthermore, it has a number of very handy features that the other two lack, and above all, it's free!

The nice thing with virtual machines that we can easily 'roll back' to a known state before starting a test session. All three of the tools mentioned above have a 'snapshotting' feature that makes 'rolling back' easy.

However, snapshots of virtual machines come at a cost: the more snapshots you pile up onto a single virtual machine, the slower that virtual machine becomes.

To avoid the performance penalty, we instead often opt for a more primitive backup strategy: we regularly make compressed copies of a 'known good' virtual machine, and restore them as needed.

Here's the trick I devised to make the compressed copies substantially smaller without loss of data:

1) Get rid of all snapshots before backing up (so the virtual hard disk becomes a single, large file).

2) Optionally, clear any temp files and so on.

3) Use a 'wiper' tool to erase any unused disk space in the virtual machine before compressing.

If you don't do this, any unused disk space on the virtual hard disks will contain more or less random bit patterns, which don't compress very well.

Yet, if you zero out any unused disk space, the unused disk space on the virtual drive compresses extremely well.

For example, I just have made a compressed backup of a heavily used virtual machine twice - first without erasing the unused space and then again after erasing unused space. The compressed file size fell from close to 80GB in size to 50GB in size. How's that for savings?

I mostly use a Windows-based tool called Eraser - it's free and open source.

The main caveat is that you have to make it erase any unused space with zeroes.

Eraser's main purpose is to make erased data irretrievable for security-purposes, and by default it will fill up any unused disk space with random bit patterns, but that is not what we're after here.

To make Eraser work for me I had to add a 'custom' bit pattern first (which is simply a zero).

There are a few variants of Eraser available - don't use the most recent 6.x version that apparently won't allow you to fill unused space with zeroes, but instead insist on using random bit patterns. That is useless for our purpose.

Instead, you have to download the older version (I used 5.8.8) which allows you to define your own erasure patterns:

http://sourceforge.net/projects/eraser/files/Eraser%205/

After installing, you need to select the Edit - Preferences - Erasing... menu. Then add a new method, call it 'Zero' and set it to use a zero as the bit pattern.

Then erase the unused space with this pattern. Then, after shutting down, you can compress the virtual machine.

InDesign Scripting: Putting TextFrames in Perspective - for Visually Oriented Scripters

kris@rorohiko.com (Kris Coppieters) — Fri, 4 Feb 2011 15:20:00 -0800

I admit it: I don't know the InDesign Scripting DOM by heart, so I spend a lot of time browsing around in the ExtendScript Toolkit Object Model Viewer.

I frequently work on very diverse projects - sometimes it's GWT/Java, sometimes it's ActionScript, sometimes it's PHP/WordPress, sometimes it's C++ or REALbasic, and so on... - and invariably, when I come back to a particular project, I need to spend some time refreshing basic knowledge.

It's like my brain 'switches' programming environment, and when I am deeply immersed in Java, I almost forget how to spell 'EkstentScript'.

The ExtendScript Toolkit Object Model Viewer (you find it under the 'Help' menu) is great for browsing the object model - but when it's been a while, it still feels like I am wading through molasses. One of the reasons for that is that I am a visually-oriented person. A picture is worth a few thousand mouse-clicks to me!

Lately, I've been revisiting BarredText - one of our latest scripted plug-ins, and to do that, I need to get back up to speed on TextFrames, Columns, Characters, Stories, and so on.
I decided I'd put in a little bit more effort, and put everything into a diagram - I've made a 2-page PDF file as a refresher I'll use next time I need to figure out how those buggers relate.

Because this might be useful to other people, I decided to release the PDF file under the 'Attribution-Share Alike' Creative Commons license:

http://www.rorohiko.com/downloads/rorohiko.blogspot.com-extendscript-textframe.pdf

I am not claiming this is error-free - if you find any errors, or can see ways to improve this, please let me know.

And if you like this - let me know too! Soon, I need to revisit tables and cells in ExtendScript - who knows, if I get enough positive feedback I might do another visual representation.

Easy Access to System Folders on Mac and Windows

kris@rorohiko.com (Kris Coppieters) — Wed, 2 Feb 2011 15:44:00 -0800

Time for a few tidbits! On my list of 'good intentions' for 2011 is an entry 'write more blog posts'.

My idea is that I want to jot down a quick blog post each time I find myself using a trick or technique that might be useful to others, and that can be explained in a relatively short blog post.

(The qualifier 'relatively' in the previous sentence is necessary - I tend to have trouble keeping the number of words in a post down to a reasonable number. I'll try to keep it short and to the point!)

It dawned on me that a lot of tricks I have personally come to find mundane and obvious can be life-changing news to some people. I had forgotten how it was for me, how nothing was obvious, when I started out doing this job long, long time ago.

If you're a hardened, experienced software developer or computer tinkerer - my blog posts are not really for you. You might find the odd gem, but most of the stuff you'll go 'duh - knew that'. But if you're starting out on a new challenge, the wee tricks I'll be describing are things that made my life easier - and I hope they'll make yours easier too.

Ok, to make a living, I am writing software, in various environments, using C++, JavaScript, ExtendScript, REALbasic, PHP, you name it... on Mac, Windows and Linux. As a project grows, invariably I 'll need a spot to put down some 'rubbish' files - temporary files created by my program that are only needed for a little while, and then can get trashed.

Sometimes, while debugging, I want to access those rubbish files with my text editor to inspect their contents - for example, to verify all is well at a certain stage of the program execution.

Mac OS X and Linux (both close relatives of Unix) have a number of spots for storing temporary files - but as on most forms of Unix, you can access that location using the /tmp path. Sometimes /tmp is not a real directory but rather an alias or link to some other place - but that does not matter too much.

If you start a command line session (go to /Applications/Utilities, and start Terminal), you can type

cd /tmp
ls

to see what's in it.

On Windows, you go to the Start button, select the Run... option, and type cmd into the Open field.

Click Ok. That brings up a command line window.

In the command line window, type

cd %TEMP%
dir

to see what's in it.

As it goes, I tend to hop all over the place in my command line sessions - using the cd command to hop from directory to directory.

Occasionally, I find myself in a command line session in a deeply nested directory, and I wish I had a Finder or Explorer window to get a better overview of the directory (aka folder) contents.

That's easy: on Mac, you simply type

open .

And on Windows, you type

explorer .

in the command line (i.e. open<Space><Period><Enter>, or explorer<Space><Period><Enter>), and a Finder or Explorer window will pop up showing the contents of the directory you're in. Then you can start dragging icons of the files you see onto various apps to inspect them. For example, I often use BBEdit, TextWrangler, 0xED on Mac, and UltraEdit or UEStudio on Windows.

If you're on the command line, and you want to inspect a text file in the current directory, that's easy enough too. I am personally well-aquainted with vi, a crusty old Unix text editor, and I use it a lot, but vi is not exactly user-friendly.

No worries - on Mac, if you have TextWrangler installed (which is a free download from BareBones), it should have asked you whether you wanted to install the command line tools. If you're not sure whether you allowed it or not - go to the TextWrangler menu, and select Install Command Line Tools...

From now on, when you're in a command line session in Terminal, you can simply type something like:

edit whateverfilename.log

to inspect the contents of the file whateverfilename.log in TextWrangler, assuming you'd have a file called whateverfilename.log in your current directory.

If you have BBEdit (TextWrangler's big brother) installed, simply substitute bbedit for edit on the command line.

On Windows, it depends on the text editor you have - everyone has Notepad or Wordpad (called write on the command line). If you have UEStudio installed, you can use that too - you could type a command similar to any of the following:

notepad whateverfilename.txt
write anotherfilename.log
uestudio yetanother.out

Now, suppose I wanted to quickly open a Finder window on the /tmp directory without needing to start up the Terminal program. If you go and look on your startup drive, you won't see it - it's there, but the Finder hides system folders like /tmp.

To get there using the Finder, select the Go - Go To Folder... menu item, and type /tmp in the dialog. Click the Go button - and you should get a Finder window on the /tmp folder.

On Windows, to quickly access a hidden folder, you go to the Run... function in the Start menu, and type in the path name. Type %TEMP% to open a window onto the temporary folder. Or type %APPDATA% to get an Explorer window straight onto the current user's hidden application data folder.

On Mac, if you need to be in the /tmp folder a lot (or any other system folder like that - /var/log for example), simply drag the little folder icon of the window for /tmp to the side bar of the Finder window - from now on you can click an icon to have instant Finder access to /tmp

Another cool one to have in the sidebar is the Originals or Masters folder inside your Pictures/iPhoto Library folder - you can get at the original files without having to go through the whole right-click, Show Package Contents routine on the iPhoto Library every time. Be careful though: you should only look at, and not touch the contents of those folders.

Windows 7 has a very similar functionality - you can drag folder icons into the Favorites on the sidebar.

Going from Finder or Explorer to Terminal or the Windows command line is also easy. Suppose you have a Finder window open, and you want to get a Terminal window positioned in the same folder.

Go to the Terminal, and type cd<Space>. Then drag the little folder icon from the Finder window title bar into the Terminal window. It will automatically spell out the correct path name - hit the <Enter> key in the terminal window and you're there.

Windows knows the same trick: in the command line window, type cd<Space> and drag the icon from the Explorer address bar into the command line window.

I hope that was useful! There's more stuff like this I could blog about - let me know whether anyone is interested!

Cheers,

Kris

Self-diagnosing code

kris@rorohiko.com (Kris Coppieters) — Wed, 12 Jan 2011 18:28:00 -0800

Been a long time since I wrote a blog post - so here's a short one, about how you can make your ExtendScript code help you diagnose issues, and how to do it without killing the execution speed.
First of all, a fairly long intro about how I make my code self-diagnosing. I'll be skimping on the details - it's all part of my intro, and I'll get to the real point I want to make later.
When writing code, I nearly always routinely add all kinds of logging to the code. For example, every single function I make gets a little 'intro' and a little, er... 'extro' ;-) ?
function blah(var param)
{
... body ...

return retVal;

}
becomes
function blah(var param)
{
  if (kTracing)
  {
   LogEntry("blah, param = " + param);
  }

  ... body ...

if (kTracing)

{

LogExit("blah);

}

return retVal;

}
kTracing is a constant that I define somewhere near the top of the script - e.g.
const kTracing = false;
LogEntry and LogExit are two functions I wrote that append their string parameter to a log file.
I won't elaborate on those - they're very simple. In my case they're part of a larger set of 'standard' routines I use in all my scripts - I also have LogError, LogWarning, LogNote...and these all append their information to the same log file, and can be suppressed by modifying a constant kLogLevel. Writing those for yourself is left as an exercise.
Secondly, I religiously test pre-conditions: things that should be true are verified and re-verified. I like using the do-while (false) 'non-loop' construct for bailing out quickly when preconditions are incorrect.
function DoSomethingWithCharacter(c)
{
do // This is not a loop!
{

if (c == null)

{

LogError("DoSomethingWithCharacter: c == null");

break;

}

if (! (c instanceof Character))
{

LogError("DoSomethingWithCharacter: c is not a Character");

   break;
   }

... body of the function ...

  }
  while (false); // This is not a loop!
}
Not sure whether this is actually any faster than try/catch/throw constructs in ExtendScript, but I do know that in a number of environments like C and C++, try/catch comes with a performance penalty, and might not be available for various complex reasons - whereas I expect do-while(false) to be relatively cheap.
I do use both constructs - I tend to use try/catch/throw more for really catastrophic issues, or as a workaround for InDesign issues (e.g. testing for 'dead' object references) whereas do-while(false) is used for 'controlled failure'.
The code above is self-diagnosing: it spits out error messages into my log file every time something is not quite right, and in my experience, the error messages are more 'pin-point' precise than what you'd get with try/catch; with try/catch I often find myself struggling a bit to find the actual location of the error.
Release versions of my scripts will typically have their log level set to zero (which means calls to LogError and friends amount to almost 'do-nothing', apart from a little overhead). When things go wrong, I modify a few constants (kLogLevel, kTracing) at the top of the script, let it do its thing, and often know what the issue is very soon thereafter.
Writing this kind of code takes a bit of extra effort - but it always pays back for itself the first time I get the first hairy bug to diagnose. It's not always possible to use the ExtendScript Toolkit for a debugging session for various reasons, and having the proper testing and logging code ready-to-go is often a life saver.
Now, that's the intro - now onto the real issue I wanted to discuss.
Adding logging code to all my functions comes at a performance penalty: especially 'deep' routines that are called from within loops are often called thousands or millions of times, and even when kTracing is set to false, this could still incur some overhead.
Now, here's a trick I often use: I use my trusty text editor (BBEdit) to make my logging code disappear and reappear as needed. Here's how it goes: I dress up all my intro and 'extro' code as follows:
...

  /*TRACEIN*/if (kTrace)
  {
   LogEntry("AdjustStory");
  }/*TRACEOUT*/

...

When the code is ready for a production environment, I do a global search-and-replace and replace

/*TRACEIN*/
with
/*TRACEIN*-/
and also (even though it is not necessary, but I am obsessive compulsive about this, so I need to do it to keep things 'even')
/*TRACEOUT*/
is replaced with
/-*TRACEOUT*/
As a result, my tracing code now becomes:
...

/*TRACEIN*-/if (kTrace)

{

LogEntry("AdjustStory");

}/-*TRACEOUT*/

...

If you look closely, you'll see the whole construct is now a 3-line comment, which will almost certainly be less costly in performance. I can only guess how the ExtendScript engine works, but I suspect that the only cost will be a tiny bit of time when the script is parsed, and there would be no additional cost during repeated execution of the function.

Furthermore, my scripts often are packaged up as .spln files (using Active Page Item Developer), and this automatically strips out all comments when creating a release version of an .spln - so when using this for .spln development, the entry/exit logging code is guaranteed to be completely gone.

When an issue arises, I simply perform the reverse search-and-replace, and re-enable my disabled logging code.

There's lot of additional things you can do with logging - I've only scratched the surface here. For example, sometimes I use an XML format for output of the logging - and the extra effort to do that is rewarded by the fact that I can use an XML editor or XML browser to selectively hide and show whole sections of the log. Anyway, depending on feedback, I might do another post some time later on a few more of these techniques.

Don't Be a Tech Support Nightmare

kris@rorohiko.com (Kris Coppieters) — Sun, 6 Jun 2010 15:17:00 -0700

Synopsis: even if you're under stress, try to communicate clearly with the people in tech support. There's a little checklist at the end of this post.

In this blog post, I want to share some issues people in tech support are facing, and raise some awareness of the difficulties anyone in tech support has to contend with.

It all comes down to communication, or a breakdown thereof.

I am sure a lot of other small software companies are facing the same issues - so please, takes this plea to heart next time you're dealing with software created by a small company.

It might come as a surprise, but in small companies like Rorohiko, tech support is being run by real, live people. We don't have a complex automated response system - if you e-mail support@rorohiko.com, you'll be answered by a real person. We go to great efforts to run a tidy, responsive tech support department. We provide world-class support on our software - whether it is free or not. We respond quickly to e-mails, most of the time within hours.

Yet we still run into the occasional tech support nightmare.

The problems we're facing are manyfold.

1) Not Enough Info

First of all, people often don't give tech support people any information at all, or way too little. You'd be surprised how many times we get an email that simply states:

"Dear support,
It does not work. Please fix ASAP!
Bye,
John"

This is sometimes prefaced with some upset diatribe about things being urgent.

We then need to guess what 'it' is? More than once the 'it' that did not work turned out to be a software from a different company all together.

(So - no, we don't do electronic PCB design. Nor knitting patterns. And no, we're not Adobe. We make task tools to help do things faster with InDesign - plug-ins, extensions, little applications. We don't make InDesign).

As we're servicing both people on Macintosh and Windows, we also need to figure out whether this person is using a Mac or Windows, and what the version is of their OS - XP, Vista, OS X 10.5, OS X 10.6? Then we also often need to know what version of InDesign they are using.

We sometimes use little tricks like looking at the raw e-mail headers of their e-mail - that might give us a clue whether they're Mac or Windows users, and sometimes even what version of the OS they're using. So if their hidden e-mail header says their e-mail program is Outlook, that's a give-away that they're on Windows.

2) We Cannot Reach The Person In Need

Our e-mails get thrashed by their spam-killer.

Or their e-mail server rejects our e-mails because it deems them suspicious - so we get our e-mails back after a few days with 'Undelivered e-mail returned to sender'.

Or our e-mails don't get through because their e-mail inbox is full.

So the scenario is like this: we get a question, and we reply, typically within a few hours. Our reply does not reach its destination.

We get an upset follow-up. We try to use a different 'sending' e-mail address, most of the time to no avail. We get an even more upset follow up,... and so on.

Sometimes people also post messages on forums saying things like 'Rorohiko does not answer e-mails'.

Luckily, most people have an e-mail signature, and such e-mail signature is a really Good Thing as it often contains a phone number. If we notice e-mails being bounced and we have a phone number, we give them a call - problem fixed.

But all too often there is no phone number - all we have is a first name and some email address @gmail.com or @hotmail.com. What's a tech support person to do?

3) Not Enough Answers

The third problem is that people often are unable to answer the questions we ask - they're often under stress, and have trouble concentrating on what we ask them. A dialog could go like this:

>>>

It does not work. Please fix ASAP!

<<<

Hi,... So sorry to hear that.

Could you let us know the name of the software you're having trouble with?

Also, we need to know whether you are on a Mac or on Windows.

Furthermore, let us know what version of the OS you're using: is it XP, Vista, Windows 7? Or OS X 10.4, 10.5 or 10.6?

And if InDesign is involved, please give us the version number - CS, CS2,... CS5?

Thanks so much!

Rorohiko Support

>>>

I am on CS4. I need to get this out by tomorrow. Please FIX ASAP! IT IS URGENT

<<<

Thanks so much for that information! That helps a bit - but we need more. What is the name of the software you're having trouble with? We have many products available, so it could be any one of them.

Rorohiko Support

>>>

The product is called Adobe InDesign. And MS Word. HELP ME!

(ok - here we can kind of guess the issue might be with our TextExporter - that's the tool we most commonly see being used together with InDesign and MS Word).

and the e-mail ping-pong drags on...

4) Don't Contact support@rorohiko.com - Post It On a Forum Instead

This is one of the biggest issue we're facing. Instead of asking us for help, some people simply assume they are on their own, and look for help with our software on public forums.

That's OK - the people on those forums are often very knowledgeable, and very helpful, and you might get a solution, or they will point you to support@rorohiko.com.

The problem is that we're kept out of the loop - i.e. if there's a problem with any of our software, we'd love to hear about it.

So, our plea: if you have any issues with our software, let us know!

5) Web Sites Do Go Down

We are using an ISP located in the USA, and we're pretty happy with them (http://www.arvixe.com if you need to know).

But every so often, just like everyone else's, our web site goes down for 10, 20, 50... minutes. It might be DNS failure, a hardware replacement,... Sometimes there's some other internet issue.

If you try to reach http://www.rorohiko.com and you cannot reach the web site here's what you should do:

1) E-mail support@rorohiko.com to let us know that our web site is down - we're not continuously monitoring it, so we're always happy if someone helps us out by letting us know.
2) Sit tight, and try again in a few hours.

Here's what you should not do:

1) Assume that because our web site is down, something must be horribly wrong
2) Put posts on public forums asking whether Rorohiko has gone out of business because their web site is down

6) We're In a Different Time Zone

Rorohiko is based in New Zealand. That means we're in a different time zone - so you might not always get an immediate response to your e-mail. We're almost a day ahead of the USA - so what is Friday in the USA is already Saturday here in New Zealand. If you e-mail us on Friday, we might already be out fishin'.

Most of the time we do keep our support department active over the weekend, but occasionally, e-mails won't be answered until after the weekend.

7) Be Impolite And Demanding On Forums

This is not an issue that affects us in tech support, but we do see it happen a lot, and I wanted to address it here, because it is also a communication issue.

Various forums like http://forums.adobe.com are run by volunteers - people willing to sacrifice their own time and knowledge for the greater good.

All too often, someone under stress busts in on these forums, and starts demanding a solution for a problem, preferably in ALL CAPS, and they NEED IT NOW.

Please, don't do that - keep in mind that software forums are like tech support run by volunteers. If a forum post does not get answered: that's how it goes. You cannot force volunteers to help you fix your problem.

Being polite helps. Being complete and concise helps too. Building goodwill by helping others in need helps too - so if you can help someone else, do it. By doing that, you increase your chances of being helped when the time comes you need it.

But don't expect help if you go bustin' in yelling you need help NOW.

Conclusion

So - if you are ever in the position of needing tech support - please think of the recipient at the other end, and help them help you.

Provide ample information from the first e-mail or post you send:

- Who are you? Make sure to leave enough info so you can be contacted. Provide an alternate e-mail address. Provide a phone number.
- What is it about? Make sure you explain what the name of the software or tool is you're having trouble with.
- What is the problem? Describe in detail what steps you are taking and where it goes wrong (e.g. something like "I then try to select the File - Open... menu but it is greyed out")
- Which platform are you on: Mac/Windows? What version of the OS? XP, Server 2008, Vista, Vista 64, Win7, Win7 64, OS X 10.4.x, OS X 10.5.x,...
- What version of the creative suite are you using: CS, CS2, CS3, CS4, CS5?
- Do you know how to create a system profile on Mac? (Go to the 'Apple - About this Mac' menu then click 'More Info...' and use 'File - Save As...' to save a system profile. Attach it to your e-mail).
- What version of InDesign are you using? CS4 has a whole range: 6.0, 6.0.1,... 6.0.5?
- Can you make one or more screenshots of the problem? If so, please do
- Can you provide a sample document? If you can, please do (but don't send a 1GB sample - try to make it as small as possible)
- Did something crash? If so, can you get the crash logs and e-mail them? If you don't know what those are, can you find someone to help you with that?

Finally, answer all questions you get in return to the best of your capacity.

Just sayin'

Cheers,

Kris

Kill The Caps Lock!

kris@rorohiko.com (Kris Coppieters) — Sun, 27 Dec 2009 14:20:00 -0800

Here's a little tidbit that has made my life a little bit easier: kill the Caps Lock on your Mac.

I don't think I've ever used the Caps Lock key - all it's ever done for me is cause pain and grief and wrong passwords or inadvertent 'shouting' in e-mails. It's a fossil from days gone by.

Go into System Preferences, select the 'Keyboard and Mouse' or 'Keyboard' panel, click 'Modified keys...'
and set the Caps Lock key to 'No Action'.

Takes all of 10 seconds!

I don't know about you, but I love it.

Cheers,

Kris

BBEdit and ExtendScript

kris@rorohiko.com (Kris Coppieters) — Thu, 26 Nov 2009 13:42:00 -0800

Quick tidbit for my fellow ExtendScripters. I am using BBEdit as my main text editor on Mac OS X, and I've set it so .jsx files are seen as JavaScript files. That adds lot of nice features that are also handy when working on an ExtendScript.

But when I am working on an ExtendScript, there is this little annoying thing: each time I started typing

  try

followed by a return, BBEdit's auto-completion would kick in and convert it to something like

  Try.these(
function() { ... },
foo.bar.bind(),
this.bat.bind()
   )

Gaah! I didn't want that!

One of these minor annoyances - not enough to spend time on, got code to write, right?

But eventually, I got annoyed enough so I did the Right Thing and looked into it.

It's simple enough to clear up:

In the Finder, go to your home folder

Go into Library, then Application Support, then BBEdit, then Clippings, then JavaScript.js, then Prototype, then get rid of the file called Try.these

Oh bliss! It's like removing a pesky pebble from your shoe!

Some time later, I'll look into creating a proper 'try - catch' autocompletion that matches my ExtendScript behavior, but for now, just getting rid of this is just great!

InDesign Scripters and Plug-In Developers: How To Avoid Confusing File Duplications

kris@rorohiko.com (Kris Coppieters) — Fri, 23 Oct 2009 22:52:00 -0700

In short: how to avoid copying or shuffling scripts and plug-ins during development on Mac or Windows.

When it comes to scripts or plug-ins, Mac alias files can be used as if they are 'the real thing' - InDesign will treat an alias file as if it is the script or plug-in it is referring to. I'll explain how you can use that feature to your advantage.

Sadly enough, a Windows shortcut file is not treated with the same respect by InDesign - a Windows shortcut file is simply ignored, so shortcuts are out.

Luckily, Windows has a 'hard-linking' feature that can be used in the same way as Mac alias files - I'll explain that too.

The basic idea is to avoid 'scattering' copies of your script or plug-in around your hard disk. As soon as you start copying stuff around, it becomes easy to lose track of which is which, and in the heat of the moment, you might get older and newer versions mixed up.

A typical scenario would be: you're creating a script that needs to work both on InDesign CS3 and InDesign CS4. You're testing and debugging - and each time you want to swap between CS3 and CS4, you need to copy the script in progress from one Scripts folder to the other.

And then the phone rings, and you're caught in mid-swap. After the phone call, you forgot: did you complete the copy or not? So, where is the most recent version - in the CS3 folder or in the CS4 folder? Frustrating, isn't it?

To avoid doing 'the shuffle', you can instead store a single 'master copy' of your plug-in or script somewhere on your hard disk.

If you are using a source code control system like SVN or CVS, the master copy would probably reside somewhere in a folder structure managed with the source code control system.

Then, instead of copying the script or plug-in to it's 'active location' (e.g. one of the InDesign plug-ins folder, or one of the InDesign scripts folders), you instead create a 'stand-in' which always refers back to the master copy of the file.

On Mac, you can use an alias file for that - pretty easy. Create an alias of the script or plug-in and plunk the alias into the proper InDesign subfolder - and everything will work as if the 'real thing' was there.

On Windows, you might be tempted to try shortcut files - but that does not work. Instead, you need to use a hard link, which you can create from a command-line window with the following command:

fsutil hardlink create [destination] [original]

where [destination] is the path of the hard link to be created and [original] is the path of the original file. Depending on your setup and Windows OS version, you might need to launch the command-line window as user 'Administrator', so you have enough privileges.

You can use this command to create hard links to folders as well as files - but I recommend you only use it for hard links to files.

Also keep in mind that this command only works on NTFS volumes (so FAT volumes are out), and both original and destination need to be on the same volume - but in most cases that's all you need.

Hard links are a low-level NTFS feature, and hard links to folders are not well supported in Explorer - and as a result, they're very dangerous things - they don't behave like Windows shortcuts, and that is where the danger lies.

Suppose you had created a hard link from a folder, and then you attempt to delete the hard link later on. Doing that in Explorer would actually also delete all the items that reside in the original folder - not what you'd expect. Explorer treats the hard link as the real thing, and when you delete a folder, it simple-mindedly will empty the folder first - blissfully unaware that the folder is still being used via the original directory entry.

Once a hard link to a folder is created, it's not easy to get rid of without also losing the contents of the folder.

In short: avoid issues - only create hard links to files on Windows; that's much safer.

There's another caveat with regards to hard links on Windows. If you use a hard link to a script file, you must make sure that the text editor program you use does not create backup files because that tends to mess up the hard link - typically, the text editor will simply rename the original file 'test.jsx' to 'test.jsx.bak' or so - taking the hard link along, so it now refers to the .bak file instead of the modified .jsx file.

Turn the backup feature off, and all will be well. I've tried it with Notepad and ExtendScript toolkit, and things seem to work well: if I edit the script via its hard link, the original script is updated as well. I also use UEStudio as a text editor - and at first I ran into problems because this editor makes .bak files by default. Once I switched that off, things worked well.

With regards to maintaining hard links to plug-ins generated from Visual Studio: make sure to use Build, not Rebuild - Rebuild will destroy the original and break the link.

So, that's it for now - hope this makes your life a bit easier!

Display Workflow-Related Meta-Info For Your Users From An InDesign Script

kris@rorohiko.com (Kris Coppieters) — Fri, 9 Oct 2009 17:58:00 -0700

When developing workflow software around Adobe® InDesign® or Adobe® InDesign Server®, as a scripter, you often find yourself attaching 'meta-info' or metadata in some form or shape to various page elements in an InDesign document.

In this blog post, the samples should work with InDesign CS and above on Mac as well as on PC, and I'll use ExtendScript for InDesign for the scripts.

But the information presented here can be applied just as well in AppleScript or VBScript. The syntax is slightly different, but it works equally well.

Meta-info would be any info that is not directly related to the page layout per se, but that needs to be associated with elements of the page layout.

Examples of meta-info you might like to attach to a page item would be things like invoice data, prices, product codes, file names, script labels, XML tags, user names, document history information, destinations, job ticket data...

In many cases, this meta-info can remain hidden from the end-user and not be displayed on the page layout at all - the data is typically picked up by various automated components of your workflow (scripts, applications, plug-ins...) and used to control processes and routing of info and documents.

One of the most popular methods to attach meta-info to InDesign page items is to use the extractLabel and insertLabel methods. These two essentially allow you to 'attach' any number of arbitrary strings to any page item, where you identify each of the strings you want to stash away with a key string.

For example, try the following script.

Open or create a document, select a page item and run the following script. (Be careful: the script has no error checking whatsoever, so it is not user-friendly. You need to select exactly one page item, and with the item selected, you need to run the script via the Scripts Palette).

// Script1.js

var theItem = app.selection[0];

theItem.insertLabel("com.rorohiko.statusquo","Whatever you want tada tada whatever you need tada tada");

Nothing apparent will seem to happen - that's OK. Now run the second script, while keeping the same page item selected:

// Script2.js

var theItem = app.selection[0];

var theData = theItem.extractLabel("com.rorohiko.statusquo");

alert(theData);

This shows how you can attach a string to a page item. I do recommend that you use a globally unique string for the keys, for example, like I did, based on my reversed domain name. That helps ascertain that you don't accidentally use the same key as another scripter.

For example, if your domain name is yourcompany.be, and you want to store, say, a user name, you should write something like:

theItem.insertLabel("be.yourcompany.username","John");

instead of

theItem.insertLabel("username","John");

The latter will also work, of course, but you always run the risk that your end user might try to run two scripts from two different developers.

Imagine she tries to use a script created by yourcompany.be and also another script created by rorohiko.com, and both scripts would use the same key username for slightly different purposes. Lots of weirdness would result.

Better be safe than sorry - so if you use be.yourcompany.username, and I use com.rorohiko.username as the key to insertLabel / extractLabel, there will never be a conflict - are we cool on that?

The string you store in the keyed location can be pretty much anything - I often store a very looong string, for example, with carriage returns separating individual records, and tabs separating individual columns, and then use .split to convert the string in to a table.

const kMyDataKey = "com.rorohiko.keyforimportantdata";

//... more code ...

// Little table of data with columns separated by tabs

// and lines separated by carriage returns

// 12 13 Kris

// 15 17 John

var myImportantData = "12\t13\tKris\r15\t17\tJohn\r";

theItem.insertLabel(kMyDataKey,myImportantData);

//... more code ...

var theData = theItem.extractLabel(kMyDataKey);

theData = theData.split("\r");

for (var recordIdx = 0; recordIdx <>

{

theData[recordIdx] = theData[recordIdx].split("\t");

}

//... more code ...

Or you could encode the data you want to stash into a big XML formatted string - that works really well too - something like:

const kMyDataKey = "com.rorohiko.thecoolKeyForXMLData";

//... more code ...

var myImportantData = "";

myImportantData += "<data>"

myImportantData += "<record>"

myImportantData += "<x>12</x><y>13</y><name>Kris</name>";

myImportantData += "</record>"

myImportantData += "<record>"

myImportantData += "<x>15</x><y>17</y><name>John</name>";

myImportantData += "</record>"

myImportantData += "</data>"

theItem.insertLabel(kMyDataKey,myImportantData);

//... more code ...

var theData = theItem.extractLabel(kMyDataKey);

// Use the built-in XML parser to parse the XML data back into its components

//... more code ...

Or any other scheme you can come up with to convert the data you want to store into a string- you can do things like ASCIIEncode or ASCII85 the data if you want to store binary info in a pure ASCII string - your imagination is the limit.

Now, what if you wanted some of this data to be visible to the end-user?

For example, the end-user could use one of your scripts to tag individual page items, maybe to let your automated workflow 'see' where it needs to insert a header and where it needs to put an image, and so on.

Wouldn't it be great if you could give the user some visual feedback in this regard?

That's where our APID ToolAssistant comes in. APID ToolAssistant was conceived as a 'scripters toolkit' and it offers a whole range of functionality that could help the serious scripter.

You might have heard about APID ToolAssistant, because it offers a very 'fine grained' event model that allows scripts to be triggered by user interaction with the document - but APID ToolAssistant has a lot more to offer than just some event-driven facilities.

One of the coolest features in the APID ToolAssistant toolkit is that it offers the scripter a way to display any 'meta-info' next to a page item. To display this meta-info, APID ToolAssistant can add little, non-printing 'labels' (also known as adornments) to any page item, and in those labels, you can display anything you like: some text, or a PNG image like a logo or an icon, all under the control of your script.

These adornments are not page items - they are instead very similar in nature to the selection handles and the overset text indicator on page item frames. They are nothing more than visual cues for the user, and they are not visible in the printed end-result.

The way APID ToolAssistant works its magic is by adding some new methods and attributes to the InDesign object model. There is a pair of methods called setDataStore / getDataStore which behave very similar in many respects to how the built-in insertLabel / extractLabel work - i.e. you store data identified by a unique key.

But there's a twist - some of the unique keys have a special meaning - they are 'magical'.

If a key starts with $ADORNMENT_ and ends with $, it tells APID ToolAssistant the stored data is something that has to be interpreted as content for a little info-label.

Install APID ToolAssistant 1.0.47 or higher (you can download it from http://www.rorohiko.com/apidtoolassistant ), and enter the following script:

// Script3.js

var theItem = app.selection[0];

theItem.setDataStore("$ADORNMENT_com.rorohiko.sample$","Hello World");

Just like with the first sample scripts you need to select a single page item, and then run the script.

Is that cool or what? (If your APID ToolAssistant has been installed for a while, it might have reverted to unlicensed mode, in which case you'd see 'DEMO: Hello World' in the little info-label).

Now, this is only a simple example - instead of a simple string "Hello World" you can actually provide an array with data to setDataStore, and through various parameter values ask APID ToolAssistant to display the label on the left, right or bottom sides of the frame.

Or you can ask it to change the background color. Or for really fancy stuff, you can display a PNG image instead of text. The possibilities are endless.

To get some ideas about what you could do with this functionality, have a look at what I've done with our FrameReporter tool at http://www.rorohiko.com/framereporter . FrameReporter is really not much more than a very thin layer of code on top of APID ToolAssistant.

For more detailed info, you need to look at the information provided in the Active Page Items Developer toolkit - http://www.rorohiko.com/activepageitemsdeveloper .

The necessary documentation is included in the free demo download - you don't need to purchase the toolkit if all you want to do is use this 'meta-info-label' feature. Check the reference manual to find out about all the variations of the adornment features.

So, keep in mind - if you want to show meta-info to an end-user, all you need is a US$25 license for APID ToolAssistant (to get rid of those 'DEMO:' prefixes added by the unlicensed version), and you can script away!

More info can also be found here:

http://www.rorohiko.com/wordpress/2008/10/15/how-to-add-indesign-page-item-adornments-using-scripting/

Apple Mail and the Drafts folder

kris@rorohiko.com (Kris Coppieters) — Tue, 11 Aug 2009 23:04:00 -0700

I use Apple Mail, and generally, it does work well. However, there's one thing that annoys me: if you don't have any 'pending' draft e-mails, the Drafts mail folder is invisible and cannot be seen in the mail window.

That seems like a non-issue, but I like to use the Drafts folder for 'repetitive' e-mail. I sometimes send out a similar e-mail to two or three people, and I like to option-drag previously sent e-mail from the Sent mail folder back to the Drafts folder to make a modifiable copy.

What I used to do in previous versions of Apple Mail was the following:

1) Type in an e-mail. Hit 'Send'.

2) Open the 'Sent' folder in Apple Mail and Option-Drag the e-mail I just sent to the Drafts folder. That makes a copy of the e-mail, and makes it available as a draft.

3) Double-click the draft in the Drafts folder, and adjust it to suit the next addressee; hit 'Send'.

4) Go back to step 2 as needed.

Because in more recent versions of Apple Mail, the Drafts folder becomes invisible if it is empty, I used the following clumsy workaround:

0) Create an empty, dummy e-mail and hit 'Save as Draft'. That puts something in the Drafts folder, and I can start using my previous trick (option-drag sent e-mail into Drafts to make a modifiable copy). Go to step 1) above.

...

That works OK, but the dummy e-mail is blank, and you end up with a blank e-mail in the Drafts folder - I don't really like that.

So, finally my current workaround is to create a single, non-blank e-mail in the Drafts folder, and leave it there for eternity. It's not perfect, but I can live with that.

The Drafts folder now has a permanent mail in it.

Not the greatest trick in the world, but it made my life a little bit easier, so I thought I'd share it.

Cheers,

Kris

Little Known Facts About InDesign Plug-Ins - There is More To It Than Meets The Eye

kris@rorohiko.com (Kris Coppieters) — Tue, 28 Jul 2009 00:59:00 -0700

Installing a plug-in for Adobe InDesign is normally fairly straightforward.

• Quit or exit out of InDesign.
• Navigate to the folder that contains the InDesign application file.
• Find the folder called 'Plug-Ins'.
• For neatness, create a subfolder inside 'Plug-Ins' - e.g. 'Third Party Plug-Ins'. Drag the plug-in icons (and possibly any associated files) into that subfolder.
• Relaunch InDesign

That's fairly easy.

But when it comes to upgrading things might become a bit more complex.

In short, you might want to first remove the previous version of the plug-in, then start and immediately exit InDesign, and only then install the updated version.

In other words - perform an 'empty' start/stop of InDesign before installing the updated plug-in.

Whether this is really necessary depends on the plug-in - most plug-ins won't need this. But if you're battling a mysterious problem, this is worth a try.

Here's what might happen.

Each time you launch InDesign it will scan the Plug-Ins folder and its subfolders, looking for any new plug-ins. If it cannot find any new plug-ins, nothing special happens - we have a bog-standard, normal InDesign launch.

But when InDesign does find a new plug-in - a plug-in it has not 'seen' before, things are different, and the launch takes longer than normal.

Most people won't notice it - the difference in launch time is not very large. If you're really observant, you'll also see some extra messages flash by in the InDesign splash screen.

Behind the curtain, InDesign is analyzing the new plug-in and extracting information from it.

For example, information on how the new plug-in can be scripted, and information about the wording on the dialogs and palettes the plug-in can display.

A lot of this extracted information is then stashed away by InDesign for 'later reference' - this to avoid having to re-analyze the same plug-in on each re-start.

So, the next time InDesign launches, it again checks for new plug-ins. If no new stuff can be found, it relies on its information stash (also known as 'cache'), and it can launch faster, because it does not have to spend time analyzing any plug-ins.

This 'trick' is called 'caching' - caches are used in many situations, to avoid needless effort to re-obtain data that has been obtained before.

For example, your web browser does it too - the first time ever you access a particular web page, it will be a tad sluggish, especially when there are a lot of graphics. Navigate to that same page a little bit later, and in most cases it will come up a lot faster.

The browser has cached the page content and instead of accessing the web site far, far away, it is showing you a copy of the page it had cached in its local web file cache. The web page comes straight off your hard disk, which is a lot faster than pulling it through the internet.

So, keep in mind: to improve launch times, InDesign caches a lot of information that is normally stored inside of the plug-in files.

Now suppose you have a plug-in installed. It's working fairly well, but there are some issues.

Some time later the software developer releases an updated version of the plug-in, which should fix the issues. You download the new version, and overwrite the old version with it.

Done? Is it that easy? Not always!

The problem is that InDesign might not scan the updated plug-in: for all it knows, it 'saw' file 'xyz.pln' before, and it still sees 'xyz.pln' - InDesign might feel no urge to re-scan 'xyz.pln'.

As a result, InDesign might be relying on the outdated info from the previous version of the plug-in that it has in its information stash.

And weird things might start to happen - things mysteriously don't work well on some computers, but work fine on others, that kind of stuff.

Morale: it might be a good idea to force InDesign to re-scan the new plug-in. To achieve that, you can use the following procedure:

0) Exit out of InDesign
1) Completely remove the plug-in you're about to upgrade
2) Launch InDesign (without the plug-in installed). It will notice the plug-in is missing, and it will erase any cached data it had extracted from it.
3) Exit out of InDesign
4) Install the updated version of the plug-in
5) Launch InDesign (with the updated plug-in installed). It will see the 'new' plug-in and re-scan it - so the cached data is now up-to-date.

Keep in mind: this info is quite general, and might not apply to your situation. But if all else fails - give it a go!

Cheers,

Kris

Some baffling behavior in InDesign CS3 scripts explained - beware of relative object references

kris@rorohiko.com (Kris Coppieters) — Tue, 21 Jul 2009 13:58:00 -0700

Lesson learned: be careful with references to page items in InDesign ExtendScript CS3 - you might be referring to the wrong object!

The issue described below seems fixed in InDesign ExtendScript CS4 - but if you need to support CS3, you should be aware of it.

Look at this code snippet:

var itemB = app.activeDocument.pageItems.item(1);
alert(itemB.id);
... do some stuff that does not affect itemB ...
alert(itemB.id);

What would you expect to happen? You'd expect to see the same id value displayed in two alerts, right?

itemB refers to a particular page item, and should continue to do so. Turns out that is not the case in InDesign CS3.

Try this:

Create a new document, and create three rectangular frames on the first page.

Create the following script:

var itemA = app.activeDocument.pageItems.item(0);
var itemB = app.activeDocument.pageItems.item(1);
var itemC = app.activeDocument.pageItems.item(2);
alert(itemB.id);
itemA.remove();
alert(itemB.id);

You would expect itemB not to be affected by removing itemA - but it is! Run the script and you'll get two different id values displayed in the dialog.

I don't really know for sure what is going on but I have a theory - it looks like itemB has 'become' itemC.

I suspect that InDesign CS3 does not really keep a 'hard' reference to any particular item in the itemB variable - instead it has what I'd call a 'relative reference'.

In other words, itemB is not fixed - it always remains equivalent to 'app.activeDocument.pageItems.item(1)' - and if the page item list changes 'underneath', then itemB suddenly will refer to another item.

After the remove(), the page item list of the document has changed - the item at index 1 is now a different item. So the variable itemB suddenly refers to a different item.

Can we create hard references that don't suffer from this issue? Turns out we can - so there is a solution.

Change the script to read:

var itemA = app.activeDocument.pageItems.item(0);
var itemB = app.activeDocument.pageItems.item(1);
var itemC = app.activeDocument.pageItems.item(2);
itemB = app.activeDocument.pageItems.itemByID(itemB.id);
alert(itemB.id);
itemA.remove();
alert(itemB.id);

That looks like a do-nothing: replace the reference to itemB with another reference to itemB

But internally, InDesign will now refer to 'the item with id=1234' (assuming itemB had an id equal to 1234). itemB.id uniquely identifies itemB, and it is not affected by items being added or removed from the page item list.

So this updated script works as expected - we see the same id displayed before and after the remove.

We can write a small helper function for this:

function FreezeReference(theItem)
{
// Harbs improved my original attempt by
// appending .getElements()[0] - thanks
// Harbs!
return theItem.parent.pageItems.itemByID(theItem.id).getElements()[0];
}

var itemA = app.activeDocument.pageItems.item(0);
var itemB = FreezeReference(app.activeDocument.pageItems.item(1));
var itemC = app.activeDocument.pageItems.item(2);
itemB = app.activeDocument.pageItems.itemByID(itemB.id);
alert(itemB.id);
itemA.remove();
alert(itemB.id);

This also works as expected.

Uncovering this issue was not as straightforward as it might seem - at first, it looked like I was struggling with a bug in our APIDToolAssistant plug-in: Harbs (www.in-tools.com) who is an advanced user of APIDToolAssistant reported some issues with the 'move into' function provided by APIDToolAssistant.

This particular ExtendScript enhancement allows you to move one page item into another very quickly; much faster than could be achieved with pure scripting - you'd do something like this:

// Some 'magic' numbers - C++ meets ExtendScript
const IID_IACTIVEPAGEITEMSCRIPTUTILITIESEXTENSION = 0x90B6C;
const kOpCode_MoveInto = 10016;

...

function MoveItemIntoItem(newParent,newChild)
{
app.callExtension(
IID_IACTIVEPAGEITEMSCRIPTUTILITIESEXTENSION,
kOpCode_MoveInto,
newParent,
newChild);
}

var itemA = app.activeDocument.pageItems.item(0);
var itemB = app.activeDocument.pageItems.item(1);
var itemC = app.activeDocument.pageItems.item(2);
alert(itemB.id);
MoveItemIntoItem(itemA,itemB);
alert(itemB.id);

app.callExension() 'calls into' the APIDToolAssistant plug-in to perform the move.

He noticed that he got invalid object references after calling this function in CS3.

Turned out APIDToolAssistant was not the culprit - after some digging I finally figured out what was going on.

Hope this is useful!

Cheers,

Kris

VMware Fusion and TimeMachine

kris@rorohiko.com (Kris Coppieters) — Thu, 16 Jul 2009 17:21:00 -0700

Been a while since I blogged; swamped in work.

This quick post to share a solution I found on Mac OS X to make VMware Fusion (or Parallels) and Apple's Time Machine backup work better together.

I use a fair amount of virtual Windows and Linux machines, and these tend to be primarily stored in large virtual hard disk files - 40GB, 60GB,... pretty massive.

Because Time Machine finds and copies any modified file, and the mere act of running the virtual Windows machines caused these large files to be marked as 'modified', I was faced with endless copies of massive virtual hard disk files to my Time Machine hard drive.

Figuratively speaking, a one-byte change in one of those massive Windows virtual hard disk files would cause a 60GB copy operation - which also indirectly forced older backup files to be erased from the Time Machine drive to make room for these behemoths.

Initially, I put all my virtual machines in a single folder, and explicitly excluded that folder from the Time Machine backup - not a good solution, but at least, my backup drive was not swamped with those big files.

But then, a few days ago it dawned on me - I could have my cake and eat it too!

The solution is to use the 'snapshot' feature of VMware (Parallels also has it) - you can make a snapshot of a virtual machine, so you can always 'undo' whatever happened to that virtual machine since the last snapshot.

The way VMware handles this is by 'freezing' the underlying virtual hard disk, and storing any changes made since the snapshot to the frozen hard disk in separate files.

And that's the solution: I first make sure my virtual machine is in a useful, stable state, and then I make a snapshot (I call it 'Base').

That effectively 'locks' the massive many-GB virtual drive - so running VMware does not cause it to be modified any more, and any changes from then on are kept in a bunch of much smaller snapshot files.

Time Machine now makes a copy of my 'frozen' many-GB virtual drive once, and from then on only backs up the changes that are kept in the snapshot files - which results in a much smaller backup set.

After a while, when the snapshot file size grows to many GB in size, I make a new snapshot, and delete the old snapshot. That 'merges' all changes that occurred 'between' the two snapshots into the main virtual drive, and starts with a fresh slate.

After I do that, Time Machine backs up the behemoth once again, and from then again only backs up the changes in the new set of snapshot files.

I now have a good backup of my virtual machines again without having to jump through hoops!

Cheers,

Kris

May 11-15 InDesign Developer Training Sessions

kris@rorohiko.com (Kris Coppieters) — Sun, 22 Mar 2009 13:58:00 -0700

If you’re involved in automation around the Adobe Creative Suite, you need to mark the week of May 11 - 15, 2009 on your calendar - there’s another Creative Suite Developer Summit coming up in Seattle, on the Adobe Fremont Campus

We’re running two training sessions this year - click the lines below for more info:

On May 11: InDesign Plugin Development Workshop - Getting Started With The InDesign SDK

On May 15: Feature Development for InDesign Using ExtendScript

Both workshops are limited to 12 seats, which will be allocated on a first come, first served basis - so don’t delay booking.

More about the Adobe Creative Suite Developer Conference can be found here:

http://niemannross.host.adobe.com/2009csbuDeveloperSummit/

As space is limited to 12 attendees per course, you should make sure you enroll early. There's also a 10% price reduction for people who enroll in both courses before April, 15.

Cheers,

Kris

New Cookbook Blog

kris@rorohiko.com (Kris Coppieters) — Thu, 16 Oct 2008 12:41:00 -0700

I've started a new blog which will be mainly like a 'cookbook' for Adobe Creative Suite scripters - how-to articles that show how to write much more powerful scripts.

http://www.rorohiko.com/wordpress

The first entry in the blog is up - it's about how you can 'attach' little icons or labels to the four sides of page items as a means of feedback to the user of your scripts. The sample script adds a little floating label with the word count to each text frame - so the user can see the amount of words in each text frame in the blink of an eye.

Check it out!

Cheers,

Kris