Must use Symbolic Links Instead of Alias for InDesign CC 2015 on OS X

Here’s a little tidbit. It’s not much, but it’s a little annoyance in InDesign CC 2015, and how I’m working around it.

It’s particular to my workflow. As everyone has their own preferred way to do things, and I suspect not many people have the same workflow as I do, this might be a worthless tip, but I am putting it out nevertheless, just in case. I hope this helps someone!

In previous versions of InDesign, you could add stuff to the Scripts Panel by means of a Mac OS X alias. With InDesign CC 2015, that does not work any more, and you must use a symbolic link instead.

Some more detail:

I do most of my InDesign script development with InDesign on a Mac. My workflow is often as follows:

– I have some Git repository with ‘stuff’ under development

– For InDesign scripts, I’ll have a project folder with the script under development and some other ‘subservient stuff’ – helper files, read me files, PHP scripts, XSLT files,…

– To test my script, I like to add it to the InDesign Scripts Panel, so I can run it from InDesign by double-clicking the script on the Scripts Panel.

I have this ‘habitual process’ to create a reference to my script on the Scripts Panel; I perform the following steps:

1) Start InDesign CC 2014 or earlier, and go to the Scripts Panel

2) Right-click (or Control-click) the User folder, and select Reveal in Finder. The Scripts folder opens in the Finder

3) Go find my source code folder in the Git repository

4) Drag the project folder containing the script and the helpers while holding Command+Option, and drop it inside the Scripts Panel folder.

That creates an alias which references the project folder inside the Git repository.

In InDesign CC 2014 and earlier, the alias works like ‘the real thing’: you get a disclosure triangle, etc…

(click to see larger version):
Screen Shot 2015-10-07 at 5.01.11 PM

Enter InDesign CC 2015. This approach does not work any more. Yay.

The workaround is to use a symbolic link rather than an alias.

It’s not as quick, but it works, at least for now.

Here’s my new procedure:

I often use a tool called cd to… which helps me a bit:

This tool allows you to click a button in a Finder window for a particular folder, and it automatically opens a Terminal window that has been ‘cd’-ed to that folder.

So, now my procedure is:

1) Start InDesign CC 2015, go to the Scripts Panel.

2) Right-click (or Control-click) the User folder, and select Reveal in Finder. The Scripts folder opens.

3) Go find my source code in the Git repository

4) Select the Scripts Panel folder icon in the Finder window. Then click the cd to… button, so a Terminal window opens inside the Scripts Panel folder.

5) Start typing


Now drag the script source folder from the repository and drop into the open terminal window, so it auto-types the full path for you. Then continue typing


Don’t forget the trailing period-character. The end result is the command to create a symbolic link, e.g. something like:

ln -s /Users/kris/Documents/Controlled/Rorohiko/Crawler .

Hit <Enter>.

The folder now appears on InDesign scripts panel and works as expected.

(click to see larger version):
Screen Shot 2015-10-07 at 5.24.57 PM

Adobe CEP Debugging – Diving Right Into It

(Note June 16, 2017: I updated  again – previous fix did not work, and also to provide better error messages).

(Note June 2, 2017: I updated to work with more recent versions of Mac OS).

Download link:

Or – how to avoid wasting time when debugging an Adobe Creative Suite Extension.

If you’re developing extensions for an Adobe Creative Suite app like InDesign or Illustrator, you’re probably familiar with the debugging facilities.

Essentially, while your extension is running ‘inside’ the Creative Suite, you launch Chrome, and visit a special URL to access the Chrome Developer Tools.

More info about all that can be found here:

One thing that cramped my style was this:

Screen Shot 2015-02-04 at 1.44.33 pm


Each time I wanted to get into the debugger, I had to first access the correct URL, then click index.html.

In the heat of cutting code, that click is really one click too many.

What I really wanted was to access this URL and get the debugger. I very, very much dislike that extra click.

So, I figured out a way to get rid of it. My trick is to patch up a file called cef.pak.

Before anything else: if you want to try this out, you do it at your own risk. I do not accept any responsibility of this thing blows up. All I can say is that it works for me. Caveat emptor.

This cef.pak file can be found in various locations ‘below’ the various Adobe Creative Suite apps.

The first step is to find the copy, or copies, of this file that you want to patch.

On Mac, it’s inside some framework.

On Windows it’s in a subfolder of the Creative Suite App.

You need to patch cef.pak for each individual application (e.g. if you only do it for InDesign, Illustrator won’t be affected).

I’ll leave locating these files as an exercise to the reader.

As an example, here I am showing you the Mac location inside InDesign CC 2014.

Screen Shot 2015-02-04 at 1.49.49 pm

And a second example: the location of the file inside Illustrator CC 2014:

Screen Shot 2015-02-04 at 1.56.29 pm


Now that you’ve found the file, you can grab my little patch program.

It’ll go searching for a little bit of JavaScript, then overwrite it with a different bit of JavaScript inside cef.pak.

Now, I am assume you’re a developer, and you can live with a few rough edges.

Hence, the patcher program is not idiot-proof, so please make sure to read carefully what follows.

First of all, you can download my patcher here:

Before anything else: do not double-click the application you’ll find inside.

It’s meant to be used in a drag/drop fashion, and merely double clicking simply launches it, doing nothing until you hard-kill it.

If you could not help yourself, and double-clicked anyway, you’ll have to find the CEFPakPatcher task in the task list and kill it. This is one of the rough edges I referred to before.

Once downloaded, decompress things; you’ll find Mac and Windows versions – there’s a bit of zip-in-zip going on.

IMPORTANT: The cef.pak file might have restricted permissions (e.g. only root can write): you’ll probably have to loosen the permission restrictions on the containing folder and on the file before using the patcher tool.

E.g. on Mac with CC 2015, I have to do a ‘chmod 666 cef.pak’ before I run the tool, then revert back with a ‘chmod 644 cef.pak’ afterwards. With more recent Creative Cloud updates, I find I also need to loosen the permissions on the enclosing directory – otherwise it cannot make a backup.

Note the two files cef_patcher_original.txt and cef_patcher_replacement.txt.

Inside these text files you’ll find two snippets of JavaScript.

function onReady() {
  if(this.readyState == 4 && this.status == 200) {
    if(this.response != null)
      var responseJSON = JSON.parse(this.response);
      for (var i = 0; i < responseJSON.length; ++i)


function onReady() {
  if(this.readyState == 4 && this.status == 200) {
    if (this.response != null) {
     var responseJSON = JSON.parse(this.response);
     window.location.href = 

In cef_patcher_original.txt  you find the original script that currently lives inside cef.pak.

Side note:  this script has a bug in it: there are some curly braces missing and the if (this.response != null) only applies to the first line behind it. The for is not part of the if, but it should be.

This script is used by the CEP debugger runtime to generate the initial web page with the clickable index.html link on it.

The second script is my patched replacement.

Instead of building a menu, I simply, and impatiently, redirect the window.location.href to the first ‘secret’ debugger URL I can get my hands on (this URL is different every time).

The patcher I made is ‘white-space-smart’: it ignores inconsistencies and mismatches in white space when searching or patching.

Because we’re patching in-place, the patched script must be exactly the same length as the original.

My patcher program achieves that by first ‘collapsing’ all spaces in the replacement script (so all multi-white-space become single spaces), then appending extra spaces until the replacement is exactly the same length as the match it found in cef.pak.

When you drag/drop the icon for the file cep.pak onto the icon for CEFPakPatcher, the patcher program will search for a match against the cef_patcher_original.txt and replace it with the contents of cef_patcher_replacement.txt (making sure the replacement is the exact same length).

It will also make a copy of cep.pak in the file cep.pak.original so you can always ‘undo’ what the patcher did.

For the Windows version, you have to change the properties so CEFPakPatcher.exe can run as an administrator, and have the necessary privileges to overwrite part of cef.pak.

Screen Shot 2015-02-04 at 2.30.15 pm


On Mac, you need to have an account with administrative privileges. Also make sure the permissions on cef.pak allow you to overwrite it; temporarily do a chmod 666 if need be.

Drag-dropping cef.pak onto the icon for or CEFPakPatcher.exe makes a copy of the file, then patches the file.

Screen Shot 2015-02-04 at 2.33.18 pm

If you accidentally try to re-patch the file, nothing will happen (as the original text won’t be found).

I expect that in future versions of the Creative Suite, the JavaScript in cef.pak will change (e.g. Adobe might fix the JavaScript bug).

In that case, you’ll probably have to adjust the contents of cef_patcher_original.txt accordingly, and possibly also cef_patcher_replacement.txt.

(That is, unless I find the time and inclination to do it and update my patcher).

If and when that happens, the easiest is to inspect the source for the debugging web page in your browser, then make an adjusted version of cef_patcher_original.txt and cef_patcher_replacement.txt.

Google ChromeScreenSnapz001

Make sure that the script in cef_patcher_replacement.txt is not larger than the script it replaces!

You also might want to inspect cef.pak with a hex editor to make sure all is as it should be.



wxMaxima on Mac OS X Yosemite 10.10 with MacPorts

How I got wxMaxima to work on Yosemite.

I recently switched from fink to MacPorts on one of my computers – an ageing 17″ MacBook Pro, because it seemed MacPorts would allow me easier access to GNU Radio.

One of the softwares I occasionally use is wxMaxima (a GUI shell around maxima). MacPorts can provide wxMaxima, and in theory all you need to do is

sudo port install wxmaxima

to get wxMaxima installed. However, that did not work: the GUI would not connect to the command-line program maxima.

From there things got bad, worse, disastrous as I got caught in MacPorts update loops and other problems as I tried to fix things.

Now, the machine carried a lot of history and crud, so I decided to start from scratch: clean install of Mac OS X 10.10.

After a few days of reinstalling, I finally came back to the same point: installing wxMaxima. Dismay: it did the same.

Maxima process terminated” in the status line, and “Not connected to Maxima!” when I tried to evaluate an expression.

So, I dug in. First I made sure wxMaxima was referring to the proper command line maxima.

I changed the wxMaxima preferences so it referred to /opt/local/bin/maxima (rather than the default maxima). No go.

Nothing in the various logs that could shed any light on the issue.

So I created a command line script called maxima in my personal bin folder, which resides in ~/bin. 

Then I changed the preferences in wxMaxima to refer to /Users/kris/bin/maxima instead of /opt/local/bin/maxima. 

(P.S. ‘kris’ is the name of my home directory. wxMaxima does not like the use of the tilde ~ as a shorthand for the home directory, so I had to spell it out: /Users/kris/bin/maxima instead of ~/bin/maxima).

In my script I had the following temporary hack:

/opt/local/bin/maxima "[email protected]" > /tmp/t.1 2>&1

This in an attempt to get a bit more info.

The contents of /tmp/t.1 gave me the necessary clue: maxima could not find sbcl.

sbcl is installed in /opt/local/bin by MacPorts, so it looked like a simple path problem.

My workaround: I now use a script /Users/kris/bin/maxima that contains

PATH=$PATH:/opt/local/bin; export PATH
/opt/local/bin/maxima "[email protected]"

(Don’t forget to chmod +x ~/bin/maxima or something similar).

Then I changed the wxMaxima preferences to refer to /Users/kris/bin/maxima instead of to /opt/local/bin/maxima

That made it work!

Programming Baofeng UV82 (and possibly others) on Mac OS X 10.10

I purchased a few Baofeng UV82 radios to play around with.

I am using the chirp 0.4.1 software (see to program the radios, and that proved sometimes elusive. I am using a Prolific-based USB programming cable I got from AliExpress.

I installed a Prolific driver for Mac OS X which I downloaded from and sometimes things would work, sometimes not.

A possibly important note: my Mac is currently running with a boot flag that allows improperly signed extensions to load on OS X 10.10. I needed to execute the command line

sudo nvram boot-args="kext-dev-mode=1"

and then reboot in order to allow my USB-to-HDMI adapters to work.

This setting might or might not affect the loading of the Prolific drivers – so if the procedure below does not work, try setting the ‘kext-dev-mode’ boot flag, reboot, then try again.

Often the chirp software would refuse to upload or download with a ‘Radio did not respond’ error message.

I think I’ve found a way to make it work for me:

1) Quit chirp if running.

2) Disconnect the programming cable. Turn radio off.

3) Start a Terminal session and navigate to /System/Library/Extensions

4) Unload the driver:

sudo kextunload ./osx-pl2303.kext

5) Start chirp

6) Connect the programming cable to the radio (but not to the computer). Turn the radio on.

7) Connect the USB of the programming cable to the computer

8) Reload the driver

sudo kextload ./osx-pl2303.kext

9) In chirp, now upload or download

By no means do I want to imply this is the only proper sequence. Maybe some of the steps above are unnecessary, or can be executed in a different sequence. I’ve not experimented that much. But this is what seems to work for me. Hopefully it helps someone else struggling with the same issues!

365 Pictures – A Year’s Worth

During 2014 (more precisely, from 30 December 2013 till 29 December 2014) I did a ‘365’ – i.e. made at least one photo each day. This is mainly an exercise to get better at photography.

It was hard at times. A fair number of the photos are what I call ‘desperation photos’. Like, it’s 5 to midnight, and I haven’t taken my photo yet, so I’d grab anything and make a picture. Hence, you’ll find pictures of bookshelves, bathroom cabinets, ukuleles… Also, most of the pictures are from around Plimmerton.

I do feel the experience as a whole improved my technique – I can recommend the exercise! The picture below is actually a slide show from Flickr; you can click on the left or right side of the image to go backwards and forwards.

It starts and ends with the same landscape shot, taken 365 days apart.

On 30 December 2013:

On 29 December 2014:

Here’s the complete 365 on Flickr:

Normally, you will not see all 365 pictures: I restricted viewing of the family pictures in the set to only ‘Family & Friends’.

Unless you register yourself on and then request to be listed in my group of ‘Friends an Family’, you’ll see slightly less than 365 pictures…

More bit stuff

Out of curiosity, I worked out the carry bit for the addition of two 8-bit symbolic words, a[7]…a[0] and b[7]…b[0].

I intend to work out some method of intelligently re-collapsing common subexpressions.

For all I know, that’ll be a non-effective, circular endeavor; i.e. what I started with might be no more complex than whatever end result I come up with.

I am currently mucking around with what I call ‘tree expressions’: a complex expression gets reduced to a tree of

expression = symbol . primarySubTree | secondarySubtree

where symbol is an atomic symbolic bit (e.g. either ‘x’ or ‘!x’), and both primarySubTree and secondarySubTree don’t contain that symbol.

I.e. I first simplify the expression to a list of terms, each term a ‘flat’ list of symbolic factors.

a.b.c | a.b.!c | a.!b.d … | b.c.d | … or whatever

then find the most common symbol (e.g. a), and convert the expression to

a.(b.c | b.!c | !b.d…) | (b.c.d | …)

then repeat recursively on both subtree, until everything is either expressed as a tree or of a simpler form.

To get a feel for how re-collapsing would work: I let my program express the carry as a tree expression, then manually reduced the carry expression to (using lower case x, y, … for intermediate results):

x = a[7].!b[7] | !a[7].b[7]
y = x.(a[6] | b[6])
z = y.(a[5] | b[5])
t = z.(a[4] | b[4])
u = t.(a[3] | b[3])
v = u.(a[2] | b[2])
w = v.(a[1] | b[1])
carry = a[0].b[0].w | a[1].b[1].v | a[2].b[2].u | a[3].b[3].t | a[4].b[4].z | a[5].b[5].y | a[6].b[6].x | a[7].b[7]

which has a nice symmetry to it.

The ‘normal’ carry expressions work out as follows (using upper case X, Y,… for intermediate results):

X = a[0].b[0]
Y = a[1].b[1] | X.(a[1].!b[1] | !a[1].b[1])
Z = a[2].b[2] | Y.(a[2].!b[2] | !a[2].b[2])
T = a[3].b[3] | Z.(a[3].!b[3] | !a[3].b[3])
U = a[4].b[4] | T.(a[4].!b[4] | !a[4].b[4])
V = a[5].b[5] | U.(a[5].!b[5] | !a[5].b[5])
W = a[6].b[6] | V.(a[6].!b[6] | !a[6].b[6])
carry = a[7].b[7] | W.(a[7].!b[7] | !a[7].b[7])

which seems to be about the same complexity.

Note: If we write the XOR operator as ^, then a ^ b == (a.!b | !a.b)

This is the same, using the XOR operator:

x = a[7] ^ b[7]
y = x.(a[6] | b[6])
z = y.(a[5] | b[5])
t = z.(a[4] | b[4])
u = t.(a[3] | b[3])
v = u.(a[2] | b[2])
w = v.(a[1] | b[1])
carry = a[0].b[0].w | a[1].b[1].v | a[2].b[2].u | a[3].b[3].t | a[4].b[4].z | a[5].b[5].y | a[6].b[6].x | a[7].b[7]

The ‘normal’ carry expressions:

X = a[0].b[0]
Y = a[1].b[1] | X.(a[1] ^ b[1])
Z = a[2].b[2] | Y.(a[2] ^ b[2])
T = a[3].b[3] | Z.(a[3] ^ b[3])
U = a[4].b[4] | T.(a[4] ^ b[4])
V = a[5].b[5] | U.(a[5] ^ b[5])
W = a[6].b[6] | V.(a[6] ^ b[6])
carry = a[7].b[7] | W.(a[7] ^ b[7])

What I like about the new form is that it starts down from the high bits. If we read it in pseudocody words, it says:

– if both a[7] and b[7] are set there is a carry (a[7].b[7] in the carry expression)
– else if a[7] and b[7] are clear there is no carry (x is 0, hence y, z,.. are all 0)
– else if a[6] or b[6] are set there is a carry (y is 1)
– else if a[5] or b[5] are set there is a carry (z is 1)

It’s not very exciting, and I don’t see any practical uses for it, but it’s satisfying to see that the program came up with a nice, symmetrical alternate expression for the carry.

What I did in my holidays

During the quiet(er) days around the end of the old and beginning of the new year, I’ve been playing around a bit with symbolic bit expressions.

Note: the contents of these post(s) should not be confounded with anything like ‘a paper’. It’s more like ‘my lab notes’: it’s not concise, and I am writing all kinds of stuff down, including wrong turns and mistakes. A proper paper is filtered – this stuff is unfiltered mucking around. Just sayin’.

I’ve only done a cursory search, but by the looks of it there is not much publicly available around manipulating symbolic bit expressions.

E.g. I wanted to do things like: if a and b are some bits, simplify a.b.c | !a.b, where | stands for ‘or’ and . stands for ‘and’.

Or, prove that the two expressions a.b.c | !a.b and b.(c | !a) are equivalent.

I am sure this software exist, as any Verilog or VHDL compiler must have this kind of code inside of it to compile complex schematics, but I did not find much during a quick search.

I’ve been attempting this kind of stuff before, but always ran out of time before it got interesting.

This time around, I managed to get the software into a more advanced state: it’s a Java program that can handle complex bit expressions.

In case you’re wondering: if a[3]…a[0] and b[3]…b[0] are two 4-bit words, and you add them, then the carry bit, fully expanded will amount to:

 | a[0].a[2].b[0].b[1].b[3].!a[3]
 | a[0].a[1].b[0].b[2].b[3].!a[3]
 | a[0].b[0].b[1].b[2].b[3].!a[3]
 | a[0].a[1].a[2].a[3].b[0].!b[3]
 | a[0].a[2].a[3].b[0].b[1].!b[3]
 | a[0].a[1].a[3].b[0].b[2].!b[3]
 | a[0].a[3].b[0].b[1].b[2].!b[3]
 | a[1].a[2].b[1].b[3].!a[3]
 | a[1].b[1].b[2].b[3].!a[3]
 | a[1].a[2].a[3].b[1].!b[3]
 | a[1].a[3].b[1].b[2].!b[3]
 | a[2].b[2].b[3].!a[3]
 | a[2].a[3].b[2].!b[3]
 | a[3].b[3])

or, converted to a tree-like format:

        a[3].!b[3] | b[3].!a[3]
      | b[2].(
        a[3].!b[3] | b[3].!a[3]
    | b[1].(
        a[3].!b[3] | b[3].!a[3]
      | b[2].(
        a[3].!b[3] | b[3].!a[3]
| a[1].(
      a[3].!b[3] | b[3].!a[3]
    | b[2].(
      a[3].!b[3] | b[3].!a[3]
| a[2].(
    a[3].!b[3] | b[3].!a[3]
| a[3].b[3]

I have the expressions for 8 bits too, but they’re even more boring. I don’t think any of this is useful, but I had fun writing and optimizing the Java code to handle arbitrary expressions of symbolic bits; the 8-bit addition takes a few minutes to resolve, and does not run out of memory.

2015 Resolution

My New Year’s Resolution for 2015: staying off Facebook. It sucks up way too much ‘real life’ time, and I am tired of glancing over irrelevant stuff, and I generally dislike the direction of where social media is going, Facebook being one of the worst offenders. This lobster is out of the pot!

However, I occasionally want to share stuff with family and friends. So that’s what this blog is about.

It’s simply about stuff that I want to share. Any stuff – there is no rhyme nor reason to what might pique my interest.

And rather than push it down everybody’s throat on Facebook: on the odd chance that you’re interested in what I am up to in real life, you’ll have to come and visit this site; I won’t be in your news feed.