olpa, OSS developer

Recently I got a complaint from an user that my FrameScript code did not work. Understanding the problem was a valuable experience.

The code does the following: it processes all images in a document and sets frames padding to zero. Initially it was a very trivial script, but then some features were added and script became more compilcated. The last change was in January when I added regarding of yet another offset parameter.

At first, I failed to reproduce the user’s problem and asked him to send me video of his actions. He did it, and I reproduced the problem on my own.

It was very ridiculous. Depending on a location in a document, the script fixes different number of images. I hardly was able to beleive my eyes. The script could not be non-determenistic.

The localization of the problem was a simple, but time-consuming task. Finally I got it.

FrameMaker doesn’t immediately load all images of a document when opening the document. Instead, it uses a sort of proxy objects. When an user scrolls to a proxied object, FM automatically loads the corresponding image object.

The problem was in the following. One of the properties of a proxy object (in my case LocY) had one value, but the real value was another.

The only solution is to avoid the proxy objects. That’s what I do now. Before accessing image properies, the script scrolls the document to the location of the image, and if it is a proxy, it’s automatically replaced by the real image.

Unfortunately, now theh script works a lot slower.

And I don’t know why the problem appeared only now, after a long time of successfull use.