I needed to create a document with an asymmetric bleed (nope, I won’t discuss if that makes sense). Doing so in InDesign is quite simple. Just tell the document preferences what you need:

set document bleed bottom offset to "3mm"
set document bleed top offset to "3mm"
set document bleed inside or left offset to "0mm"
set document bleed outside or right offset to "3mm"

When the document showed though, the bleed was the same for all four sides of the page. I checked the code, there should be no bleed on the left, but the program stubbornly refused to do what it was told. I then checked the dialog to set the bleed and lo and behold, setting the bleed manually didn’t work either. There is a default setting to make the bleed uniform, no matter what.

The innocent (and active) chain-symbol next to the values gave me a clue: InDesign does not switch to non-uniform just because I told it so, it needs more convincing. Some rummaging in the dictionary using AppleScript Editor later and I found a property called document bleed uniform size. I added the following line before setting the bleed:

set document bleed uniform size to false

And I got what I wanted. The working block of code needs to be in that order:

set document bleed uniform size to false
set document bleed bottom offset to "3mm"
set document bleed top offset to "3mm"
set document bleed inside or left offset to "0mm"
set document bleed outside or right offset to "3mm"

Lesson learned: Always be concise when telling InDesign what you expect.

One of the most used constructs would be accessing the folder Documents located in the user’s $HOME, for example. The easiest way is the following string of commands:

set myDocumentFolder to path to documents folder as string

The result is the colon-delimited path as string, e.g. MacHD:Users:username:Documents:.

If you need the path to hand it over to a shell script or any other process requiring the Unix way of wording a path, use this approach:

set myDocumentFolder to POSIX path of (path to documents folder as string)

No surprise here, the answer will be something like this: /Users/username/Documents.

But what about accessing the user’s Library folder? If we continue like this:

set myUserLib to path to library folder as string

All we get is MacHD:Library:. Is there a way to tell AppleScript which Library folder we are really interested in? There sure is:

set myUserLib to path to library folder from user domain as string

Firing this command results in the path we are looking for: MacHD:Users:username:Library:. Telling AppleScript the domain we are interested in does the trick.

There are three domains at our disposal (there are actually some more, but those will be the subject of another post):

• user
• local
• system

To cut a long story short, here are examples for the other two domains and the corresponding results:

• set myLocalLib to path to library folder from local domain as string returns MacHD:Library:
• set mySystemLib to path to library folder from system domain as string returns MacHD:System:Library:

It seems, that using from local domain is superfluous in regard of the folder Library, but good programming practice (and the resulting peace of mind) implies, that we should use the construct and be save from surprises later.

I found one deprecated call (in two incarnations): listcats expands to list_cats, but the beauty in using the Bundle is, I just exchanged it to expand to wp_list_categories and I was done. I don’t have to remember which calls are deprecated, I’ll just have to make sure to check the Bundle as soon as new lists with deprecated calls show up and exchange them. The only “clear and present danger” I see in this approach is: What do i do, while not using TextMate? But that holds true for almost anything handled by a Bundle in TextMate. (I just found out, that the editor in WordPress does not close HTML-Tags when ⌘ – ⌥ – . is pressed. )

Kudos to Joost for picking up the task. Thanks, really.

I’m going to test it later today.

sudo ln -s /Users/admin/FBLogs /Library/FrontBase/LogFiles(OS X)
Creates a symbolic link to the directory FBLogs (the directory needs to be created first) named LogFiles in your FrontBase-directory. If FrontBase “sees” this directory, all logs will be created and written there instead of the standard-location in Databases. If you are using Linux or Unix, choose a convenient location on your hard-disk.

Now you’re ready to log (and roll), but you have to tell FrontBase first. Fire up sql92, connect to the database in question and use

SET WRITE SQL TRUE GLOBAL;

to convince FrontBase to start logging. To turn logging off, use

SET WRITE SQL FALSE GLOBAL;

The logfile-name is the one with “sql” added, so [name_of_your_database].fb.sql is the file the commands shown above use for logging. Said file will grow to astonishing proportions in a very short time, on a busy database, that is. If you want to use a new file while logging is active, use

SWITCH TO NEW SQL LOG;

The current file will be renamed to [name_of_your_database].fb.sql.YYYYMMDDHHMMSS and a new file named [name_of_your_database].fb.sql will be created and used (keep this in mind when using tail -f).

Again, this is supposed to be a debugging-feature, not something you enable and let run forever. Check out the documentation, there is more to logging in FrontBase; especially the explanation of the contents of your log files.

Hope this helps, if you tend (like me) to forget these commands, bookmark the post.

• Written in Erlang
• Flat-file and document-centered
• Replication built in
• Runs on
  1. Linux
  2. OS X
  3. Windows
• Open Source

What’s not to like? And since the local database is replicated with the peers, no backups. But don’t forget to put two or three machines in another building.

A short explanation regarding split(): The function allows the programmer (a.k.a. us) to translate a string like ‘A-B-C-D’ into a character array, using (in this case) - as delimiter, or marker where data ends or begins during the translation.

Back to AppleScript, there is no function to split a string easily; the “whys” seem to be buried in the vaults of the developers. Not that we wouldn’t need that kind of functionality on a recurring basis, though. But since AppleScript has a property called text item delimiters, we could make use of said property, couldn’t we? Let’s take a look at the code first:

	set myTestString to "1-2-3-5-8-13-21"

	set myArray to my theSplit(myTestString, "-")

	on theSplit(theString, theDelimiter)
		-- save delimiters to restore old settings
		set oldDelimiters to AppleScript's text item delimiters
		-- set delimiters to delimiter to be used
		set AppleScript's text item delimiters to theDelimiter
		-- create the array
		set theArray to every text item of theString
		-- restore the old setting
		set AppleScript's text item delimiters to oldDelimiters
		-- return the result
		return theArray
	end theSplit

The first two lines make use of the handler and display the result in the, appropriately named, “Result”-window in Script Editor.app. The Handler theSplit expects a string and the delimiter to be used as arguments. We need to store the current setting of text item delimiters first. (Never ever override the delimiter without restoring it as soon as you are done, debugging of larger scripts can be a real pain should you forget to restore, believe me.) Then we override the current setting with our delimiter. The theArray is populated with the split-up contents of theString, the delimiter is restored and we return the result.

I’m aware that I could have just used theString and overwrite it with the result, but doing it this way allows the insertion of another handler to convert the array to a different data-type, if needed.

The other thing I’m aware of is the fact, that the code shown above ruins my XHTML-conformity for good, a sacrifice for you, dear reader.

If you could scrape some definitions from your stylesheet, then—depending on the traffic on your website—getting rid of some stuff might mean less traffic. Besides, knowing your code is clean makes you feel better, believe me. The idea is so obvious, I wonder why nobody came up with something like The CSS Redundancy Checker a long time ago. IMHO, the work of a genius.

The author hints, that the functionality might come as a TextMate-Plugin in the future, BTW.