There was once a time when Illustrator was one of my favorite applications (most Adobe applications were at one point). But now I dread clicking the icons in my dock for fear of what non-sensical problem I will be faced with in using them.

First off, I am not going to apologize for not posting in such a long time. This blog is free and you get what you pay for. At the same time, any parent that reads this blog will understand when I write that babies change everything. Let me do that again with a bit more emphasis for all of those non-parental types out there:

Babies change everything.

I'm not saying it's a good thing (it is for most people, myself included), nor am I saying it's a bad thing (although there have been times already where I yearn for "the bygone days"). All I'm stating here is that right now, when given the choice between eating a sandwich and writing a blog post about whatever is on my mind at that given time, the sandwich wins. Every time.

However, I've missed the blog. I miss the ability to pontificate on anything I want at anytime I want about things my wife either already knows about (so there's no sense in complaining to her) or doesn't affect her (see previous parenthetical comment). Time is, at minimum, a very precious commodity, but I have received a couple calls from folks wondering when I am going to write again.

So, here I am, in front of the keyboard (with a slightly gummy "H" key). But what to write about? Certainly, I could write about my (mis)adventures with REALbasic and Xcode. I recently wrote an Undo system in REALbasic (that was hard), I've gone full-blown Subversion with all of my working code (that was easy), and there are the current hobbyist-vs-professional debates (both camps need to learn to live with each other and I have some ideas on how to make that happen), and whether iPhone compilation in REALbasic is a good idea or not (it isn't).

But my thoughts are wandering around other topics as well. Like the simple pleasure I get from cleaning the baby bottles at night because it gives me a chance to reflect on my busy day. Or the general, typical, yet not entirely unfounded concerns I have as a new parent (and there are many).

When I first started this blog, it was a re-telling of my day and some of the odd situations I find myself in. Then, programming took over my spare time, and all I wanted to do was talk about that. Amelia (said baby) changed all of that and now my thoughts drift between those two aspects of my life, usually with ease, but often not (the context of my basement office has changed from needed hideaway to evil necessity).

I'm still trying to sort out what, exactly, the focus of this site will be, and as I write this, I have the feeling its going to be about a little bit of everything, a public diary of sorts of a formerly wayward displaced Californian now late thirty-something coming to terms with the joys of family, the burden of responsibility, and the thrills of programming.

Maybe I'll throw a little chess in there for good measure.

At minimum, this place could use a new coat of paint.

More to come...stay tuned.

Here is the rundown of the new features that are included and/or are now fixed:

• Custom delimiters between data points.
• User selects when and where catalog metadata get saved (At beginning, at end, or not at all).
• Simple Cataloger is now a document-based application. Multiple catalogers can be run at the same time, and catalogers can be saved for later reuse.
• Added a Recent Items menu, and support for opening the most recent item by default when starting the application.
• The frontmost cataloger window can be saved as the default preferences.
• Verified Mac OS 10.6 (Snow Leopard) compatibility.

I'm still not entirely clear as to what happened with the v3.1 release, but the v3.1.1 update sorts everything out, is thoroughly tested, and uploaded to the server. So, what's done is done, and it's not so much about the mistake as it is the recovery. It took a little longer than I had wanted (and expected) to get this out the door, but it's done and that's what's important.

I hope you find this new version as useful as I do, and, as always, I'm happy to hear any and all feedback you have.

Well, I made a huge mistake of epic proportions: I complied the wrong code and posted it for all of the world to download. The one that got posted was an alpha I had kicking around, but wasn't feature complete and still had the moral equivalent of a few wires and hoses hanging out of an open hatch. It wasn't the final product.

I could blame this on a number of things: I was in a vaguely self-imposed rush, I have a sleep-deprived, addled brain from caring for a newborn, whatever. But there really isn't an excuse. Frankly, I'm mortified by this, and to cap it all off, I can't seem to reconcile what is supposed to be the correct set of code. For someone who desperately would love to become a full-time programmer, I fell flat on my face.

The earliest I will be able to deal with this is this weekend. So, until then, I'm going with the notion that it isn't about the mistake, it's about the recovery. To that end, please feel free to download the Simple Cataloger 2 here...

http://www.oatmealandcoffee.com/softwar ... loger2.zip

...and please use this code to unlock all of the features:

OCSC20-4W3R2N-0M7R6R-37608

Sorry about this, everyone. You deserve better. A fix is on the way.

Simple Cataloger 3 is now available. There are quite a few changes in this version, and they are largely as a direct result of feedback from our users.

• Custom delimiters between data points.
• User selects when and where catalog metadata get saved (At beginning, at end, or not at all).
• Catalog settings can be saved for later use. Also added support for a Recent Items menu.
• Multiple catalogers can be run at the same time. For preferences, the frontmost cataloger window can be saved as the default preferences.
• Verified Mac OS 10.6 (Snow Leopard) compatibility.

The single biggest change is that Simple Cataloger is now free. I enjoy working on this project, and to all of those people over the past couple of years that have purchased licenses and sent in feedback, I would like give my most heartfelt gratitude. I will continue to support the software and all of you, and I hope everyone enjoys the new changes. I look forward to hearing what everyone thinks.

The other major change is that there is now an open source branch of the code hosted in the ARBP's Source Code Repository. Please note that this is not the same code that is used in the commercial version hosted on my site and I will be independently developing that as needed. As such, there are still some unfinished and unpolished portions of this project, though, for the most part, it is clean code. I'm submitting it as open source because it contains solutions to a variety of interface problems in Mac OS X that I have found in a variety of locations and I hope other developers within the REALbasic community can find use with what is contained inside. This is simply my saying "Thanks" to the REALbasic community as a whole.

This has been sitting on my list of things to do for far too long and external forces have finally pushed me to actually do something about it. Enjoy!

I have an update to an earlier post about Applescripting InDesign, Applescripting for Adobe and Kindergarten Scissors: A Study in Object Transformations Across Versions.

Just a quick recap, here is how the commands looked in CS2 and CS3:

Adobe InDesign CS2
rotate text frame ¬
by fixed ¬
around anything ¬
considering current rotation boolean ¬
transforming content boolean ¬
considering parents rotation boolean

set theResult to move reference ¬
to insertion location ¬
by number | string ¬
binding binding

Adobe InDesign CS3
Rotating then required an undocumented matrix:

tell application "Adobe InDesign CS3"
	set myMatrix to make transformation matrix with properties {counterclockwise rotation angle:90, horizontal translation:-217.5, vertical translation:217.5}
	transform myLayoutObject in pasteboard coordinates from center anchor with matrix myMatrix
end tell

Move was unchanged from CS2

Adobe InDesign CS4
I now have CS4, and was able to look up the Rotate and Move commands.

Rotate is back when searching for it in the dictionary, but it's not Rotate as we know it. It's really more of an abstract command meant to be performed on one of those ill-documented transformation matrices.

rotate matrix (verb)Rotate the transformation matrix. (from Layout Suite)

function syntax
set theResult to rotate matrix transformation matrix ¬
by angle fixed ¬
by cosine fixed ¬
by sine fixed

result
transformation matrix: The rotated transformation matrix

Actually rotating an object in the layout is still left to the transform command, which mentions nothing about rotating. Essentially, rotating an object is unchanged from CS3. Which makes me wonder why was this command even necessary? But, again, to find how to rotate an object is an exercise it "What were the programmers thinking at the time they wrote this?".

• Searching "rotate" brings up eight hits none of them having to do with rotating an actual object in the layout, only abstract transformation matrices and other devices and properties.
• Searching "rotating" returns 14 hits in four functions: transform again, transform again individually, transform sequence again, and transform sequence again individually. The only mention of rotation is in the function description: "Transformations include moving, rotating, shearing, scaling, and flipping."
• Searching "rotation" returns 47 hits almost all of them rotation angle and absolute rotation angle properties of a variety of classes. I can't decide if this is reasonable or not, but to perform a transformation as an actual verb/command, we're still left with the abstracted transformcommand, which we know doesn't appear when searching for the painfully obvious "rotate". Besides, the sister command Move is called as a verb and here we're not. The interfaces to two commands usually grouped together are altogether different. So, no, properties aren't entirely reasonble, are they?

Move, surprisingly but not all at that time, is unchanged from CS2/CS3.

Words escape me.

Anyone who has used Adobe products for any length of time knows that UI consistency is not one of Adobe's strong points. In fact, for the uninitiated, things have gotten so bad over at Adobe that there is even a blog about it over at Adobe Gripes and though it seems Flash is the biggest culprit, all of the applications are guilty of some nonsense. Anyone who has scripted Adobe products knows that their UI inconsistency carries over to their APIs as well. I've complained about this in the past¹ and I'm not the only one to do so, either.

For the first time, I really, really need to script the processing of PDFs because eBooks are popping up freakin' everywhere and vendors want PDFs if I can't give the native format, which I can't (yet and it will be a long while before I can). I'm not asking for a lot of depth here. I just need to compile, optimize, and crop multiple sets of PDFs. This type of work I can set up in other applications, Adobe's included, fairly easily.

None of those basic production commands in Acrobat are available to Applescript, however. It seems that Adobe has decided to abandon further Applescript (without really telling anyone) and focus entirely on Javascript. So, what few Applescript commands that do exist look like they were simply abandoned and clearly not brought to the same implementations of the rest of the Creative Suite. For the Applescript folks they have offered (what I guess is) a laurel leaf, albeit a rotting one with most of the leaves lobbed off:

-- get the title of an open document
tell application "Adobe Acrobat Professional"
	do script "this.info.title;"
end tell

"do script". That's it.

So, I can automate Acrobat, but only on its own terms, which are both cheesy and lame. Communication is strictly limited: I can't send data to it, but that doesn't matter because even if I could I can't get data out of it, and it looks as though I'm pretty much forced to debug the code in Acrobat's Javascript debugger.²

At the same time, all of the other Adobe products that matter to me—InDesign, Photoshop, and Illustrator—have very robust, if not feature-complete implementations (though frustratingly inconsistent and/or poorly documented at times). So, why no Applescript support in Acrobat, Adobe, when clearly you care enough about it everywhere else? What is it about Acrobat that sets it so far apart from the rest of the line-up that you felt Applescript was unnecessary, despite the fact that all of the other production-related applications have robust PDF support? It's nonsense like this that makes people want to throw chairs.

The do script command is nothing more than a crappy cop-out of them not doing their job to the level their price points imply and Adobe Acrobat is preventing me from me doing my job effectively. I've found alternatives to all of Adobe's apps at home, but unfortunately I'm burdened with Adobe forever at The Day Job and have to suffer the consequences of their poor decision-making (how are those layoffs working out for you guys?).

Even if do script were actually, you know, useful, the Javascript implementation still isn't feature-complete even though were are now on version 9 of Acrobat...of course. Why would it be any other way?

It seems I can combine PDFs, and I can crop, but I can't optimize. Ironically, of all the things I need to do that is the single command I need more than anything. Optimizing a PDF is necessary to go from a print PDF to the "web PDF" that all of the vendors ask for and are so much easier to FTP. I can go from 3 GB of PDF to <300 MB, and the process may only take a couple clicks, but it can take hours to run through a large enough book, and it almost entirely consumes a machine in the process. I have literally thousands of books to go through, and scripting this would save me tens of thousands of dollars each year. It's a perfect job for my automation Mac and it would be a huge win for me. But can I script it? No, because that would be too freakin' logical, and that just reinforces my dislike of Adobe. It seems just when I think I have a solution at my fingertips, they have some reason why I can't do it properly or, in this case, at all.

Essentially, even after all of these years and upgrades, there is no way I can reasonably (comprehensively) integrate Acrobat into my other well-established, Adobe-centric workflows, and that whole notion is just laughable. Everything is so seemingly well-integrated, yet Acrobat stands alone. I have Applescripts that are thousands of lines long that save me countless hours (at least thousands) of manual work each year. In one set of scripts I send calls to Adobe InDesign, Adobe Illustrator, Adobe Photoshop, the Mac OS Finder, and Microsoft Excel all seamlessly working together. The single gaping hole in all of that is Adobe Acrobat, and up until now I was able to work around Acrobat's severe scripting limitations.

But now that eBooks have taken on a whole new priority, and all of the vendors that I work with take PDFs out of convenience, I desperately need to script the processing of PDFs. I don't have a choice here. I have to find a solution. Adobe is, in its own weird way, keeping me from doing my job in a reasonable fashion.

Since I can't do what I want with Adobe's software "out of the box", my last alternative is to call an Adobe rep and see if they have a server-based solution (ugh, there goes another point of IT independence) that can help move a lot of PDFs in a short period of time. I'm sure this is going to cost me a whole more than it costs them to pay one of their programmers to write some code over the course of a week or so and they can just fix this for everybody.

Perhaps that's been their plan all along.

---

1: Two blog postings come to mind: An Applescript and Adobe Rant and Applescripting for Adobe and Kindergarten Scissors: A Study in Object Transformations Across Versions

2: These are assumptions on my part since I haven't actually used this command before. However, the Applescript dictionary entry for do script only shows this in Script Debugger:

do script (verb)Perform a JavaScript. (from the miscellaneous standards suite)

COMMAND SYNTAX
do script unicode text ¬
file alias

PARAMETERS
direct parameter, optional, unicode text, The actual text of the JavaScript to perform.
file, optional, alias, The file containing the JavaScript to perform.

I don't see any way to send arguments and return values. Do you?

I hope that children will be inspired to take up music. Why not? Enough baseball, enough football in this country! I cannot believe the yardage that is given to sports. How can they speak so long about a man hitting a ball?

Very well put. As much as I enjoy a good sporting event, I always thought skilled musicians of any genre were much more interesting.

Link: ‘Please don’t deactivate me’

All child-rearing books are comprehensive, detailed, and inapplicable to children.

---

The guideline that 7-day-old babies are supposed to poop three to four times a day falls under the same context of the guideline that states I am supposed to eat five fruits and vegetables a day.

---

Now I understand why new fathers respond with "Everyone is doing great!" when asked "How are the Mom and new baby?". The reality is far too complex for casual conversation, the uninitiated would never have kids if they knew the truth, and nobody wants to be rude. This goes back to my personal rule of "Don't ask the question for which you really don't want to know the answer."

---

Pregnancy is a hassle, labor sucks, and birthing is gross, but they answer that fundamental question of "Why am I here?". Parenting a child fulfills your part of the evolution equation.

Amelia Regan was brought forth unto this world on November 3 with a lovely head of golden blonde hair and what look like are going to be gorgeous blue eyes. But, perhaps I'm a bit biased. Mom, Dad, and The Kid are doing just fine.

Just to confirm the immediate suspicion, Amelia is named after the aviator Amelia Earhart. Names were tossed around that focused on women who kicked some butt during the time they were here, and Amelia Earhart certainly did enough of that. The name Amelia was my pick, and special thanks to Renee for allowing me the privilege.



Let the multi-tasking begin!