Mimsy: Hacks

I’ve been neglecting my Color Computer posts for a while now. It’s not that I’m not using my CoCo, it’s that most of what I do is play old 8-bit games and fool around with simple programs in old books.

Over on Allen Huffman’s blog earlier this year we had a short discussion about Rainbow Check and the usefulness of its various iterations when typing in TRS-80 Color Computer code from The Rainbow.

In fact, The Rainbow went through three variations on how to preflight your code as you typed it that, weirdly, few if any other magazines or books picked up on. The first verification tool is that The Rainbow was the first such magazine, almost from the start, to present their code listings in 32-character lines. This meant that, when typing code in on your Color Computer you could look at the left-most and right-most columns to get a good idea of whether you had typed the code correctly.

This was pretty simplistic, of course. Typos that didn’t involve adding a character or losing a character would only be obvious if that typo happened to occur at the beginning or end of a line. So in January of 1983 The Rainbow introduced their Rainbow Chek utility. It, too, was very simple: each listing provided a table of numbers representing how much memory should have been used up by your code at various checkpoints. When you reached that checkpoint (i.e., line number), you would run the utility. It would tell you how much memory the code used, and you could verify that number against the printed table.

This was really only useful for fat-fingered extra/missing characters—which the 32-character line already helped with—and for typos in BASIC commands. Typos in BASIC commands prevent them from tokenizing. As long as the typo doesn’t itself represent another command, that will alter memory usage.

Despite those limitations, and combined with the 32-column validation, the first “Rainbow Chek” was very useful compared with the absolute nothing every other publisher provided.

There were, however, a huge class of errors that Rainbow Chek wouldn’t catch, so in February 1984 they introduced Rainbow Check Plus. This provided a true checksum based on the tokenized BASIC commands and the ASCII codes of non-tokenized characters.

To get the built-in Reduce File Size Quartz Filter to reduce file size, I also have to check “Optimize images for screen”.

One of the most popular pages on my site is how to create a Reduce File Size Quartz filter. Sadly, while it appears to be still recommended by many people, it hasn’t worked for me for a long time. But I recently decided to write a color cookbook and I wanted to make the PDF available for download.

I don’t like having multiple sources for multiple destinations. That way lies madness. I want the same source to provide for different destinations. But the file destined for print¹, because this book is focused as much on the images as on the recipes, was large even for modern downloads. If it turns out to be a tenth as popular as Quality Reduced File Size I don’t need people downloading hundreds of copies of a 34 megabyte file every day.

So I decided it was time to take a look at why Quartz filters stopped working so long ago, or at least how to get them working again. To be honest, I’m still not sure what’s going on. But I was able to get the stock Reduce File Size filter working again.

The executive summary is that I have to turn on Optimize images for screen if I want Reduce File Size to actually reduce file size. Read further for what I discovered in greater detail, as well as advice if you have multiple copies of your aging custom quartz filters.

First, Quartz filters no longer show up at all on Print, even from Preview. I have to open the PDF in Preview and choose File:Export to get the list of filters. Even then, though, if I just choose “Reduce File Size”, the resulting file is always exactly the same size as the starting file.

Apple’s help page says that, to reduce file size, you have to:

Do one or more of the following:

• Compress PDF graphics to presentation quality: Select the “Optimize images for screen” checkbox.
• Convert all graphics to JPEG format: Select the “Save images as JPEG” checkbox.

Make sure Script Menu is enabled in Script Editor.

I am an information packrat; I never throw out emails, and have messages dating back to the last century. I manage this using hierarchical mailboxes to keep the archives from cluttering up my Mail window.

I have Rules set up to send various messages directly to the mailbox where they should be stored, and then Smart Mailboxes to display unread messages of various classifications: Unread Mail, Unread Mass Mails, Unread Spammy, and Unread Junk, each less critical than the previous.

In the past, it’s been easy enough to see where any message is stored. The macOS Mail app has acted like any other application on the Mac: documents (i.e., messages) could display the full path to the document by option-clicking the document’s title (i.e., the message’s subject) in the window’s title bar.

As far as I can tell, this is no longer possible. Mail has been moving away from a document-based model toward a flat, search-based model, and no longer makes it easy—or even possible—to find the full path to a viewed message. The immediate parent mailbox’s name is displayed in the sidebar, but the mailbox’s parent is nowhere to be found. So that I can see easily enough that the order I’m waiting on is in the eBay mailbox. But not that the eBay mailbox is in the Purchases mailbox of the Finances mailbox. The latter two are completely hidden.

Obviously, however, the Mail app itself knows where these messages are, and that information can be displayed using AppleScript.

All this for a script that will be used no more than a handful of times, to restore long-replaced data from the nineties. It’s time to quote Douglas Adams again.

I have a well-deserved reputation for being something of a gadget freak, and am rarely happier than when spending an entire day programming my computer to perform automatically a task that it would otherwise take me a good ten seconds to do by hand. Ten seconds, I tell myself, is ten seconds. Time is valuable and ten seconds’ worth of it is well worth the investment of a day’s happy activity working out a way of saving it. — Douglas Adams (Last Chance to See^•)

In A HyperCard Time Machine I wrote that I also seriously considered writing the script as a JavaScript (JXA) app. In fact, I did write the script as a JavaScript app. It was a toss-up to the end which version I was going to use, so they’re both fully-working versions.

One advantage the JXA version has is not requiring old-school, BASIC-style manipulation of strings to extract the current card number and the total card count from the window title. Instead of grabbing the location of the final slash, which required serious gymnastics in AppleScript, the JavaScript solution can use a regular expression that is both shorter and more reliable:

JXA also doesn’t use tell blocks. It places the application in a variable, and the things we want to tell it to do can be handled at any point without worrying about how a tell block affects the syntax. At the beginning of the app, I did:

This gave me the current application and System Events. The current application is necessary for dialog with the user, which is why I’ve also included the Standard Additions on it. The Standard Additions include Display Dialog and Choose Folder.

This was a tool for an early role-playing game. And looks it.

My second programming job out of college started as a HyperCard stack. HyperCard was an amazing tool not just for programmers, however, but especially for the weekend programmer or even the weekend non-programmer. It didn’t require any programming to get started. Just put some text placeholders on a background card, some buttons, maybe add a pre-created action to a button such as “move to next card”, and you had a very simple visually-oriented application that responded in a manner customized for you and your data.

There were a lot of non-programmers who used HyperCard and graduated to weekend programming. Because after you wrote your text or placed your graphics or added a button with a standard action, if you wanted to add code to that object, you could. You might start with slinging messages from object to object, or performing simple math on one of the text placeholders.

HyperTalk was not object-oriented in the sense that programmers mean when they talk about object-oriented programming. But it was object-oriented in the sense that programmers explain object-oriented programming to non-programmers. Every object on the screen could contain code that responded to specific actions. Each card could respond to keystrokes. A text box could respond to typing. Cards, text boxes, buttons, and images could respond to mouse actions. Keystrokes, mouse actions, and custom functions were all messages. And each object could send messages to other objects.

HyperCard was often used for databases; the card metaphor was especially apt for that. For example, I had a database of superheroes and supervillains in the Men & Supermen superhero role-playing game.

The game used meters, but clicking on the word “Height” on the character sheet would calculate and then display the character’s height in feet and inches:

An example pre-Ventura.

The same page post-Ventura.

I’ve updated my searchablePDF (Zip file, 8.9 KB) script with a workaround for new behavior in Ventura. As you can see from my archive of old promotional cookbook pamphlets I’ve been using it extensively—and I have a lot more to come! Reading these old books and trying out some of their recipes has been ridiculously fun, and even occasionally tasty.

Recently, a friend of mine gave me an old recipe pamphlet in very bad shape; but it isn’t currently available on any of the online archives, so I decided to scan it anyway, more for historical purposes than as a useful cookbook. This was the first archival scan I did since upgrading to Ventura, and when I was finished and created the PDF, it was practically unreadable.

It was also a lot smaller than the source images. All of the previous PDFs had very predictable file sizes. When running this script under Monterey, all I had to do was sum up all of the source images (easily done by just doing Get Info on the folder they’re in) and that was the size of the resultant PDF file.

In retrospect, it sounds like in Monterey, where I originally wrote the script, PDFKit was re-using the original image data. I always scan at somewhere from 300 to 600 dpi. In Ventura it seems to be regenerating the image data and using the lower resolution of PDFs to do so. PDFs use 72 dots per inch; but PDFKit in Monterey did not downgrade the actual images to 72 dots per inch. Ventura does.

No problem, I thought, I’ll just increase the image’s size before creating the PDFPage. This worked—to improve the image’s quality. But the PDF opened in Preview as if it were bigger than the screen! Sure enough, Preview reported the document as being some immense number of inches wide and tall.

While flailing around looking for a solution, I noticed that if I didn’t bother trying to normalize the images to always be the correct ratio (i.e., for a 4x6 book, the ratio should be ⅔) but just assigned the 4x6 pageSize to image.size it both maintained the image quality and it created PDFs of the correct size in inches.

Because the image wasn’t normalized to the PDF’s size, however, there was weird white space either vertically or horizontally, depending on whether the original image was slightly too wide or slightly too tall.

The searchablePDF script creates PDFs that can be searched for text, using VisionKit to recognize the text and PDFDocument to create the PDFs.

I’ve recently acquired several old cooking pamphlets from companies such as Pet Milk, Borden, and so on, that are not yet available on the various Internet vintage cooking archives. I thought it would be nice to scan them myself, but a simple scan with a desktop scanner means they’re just images without the ability to find a particular recipe or ingredient in them.

Of course, the obvious thing to do is OCR them or even just retype them, and then reformat the text in a word processor and save that to PDF. I have done this with some texts, such as a Franklin Golden Syrup pamphlet and a Dominion Waffle Maker instruction manual.

But part of the thrill of collecting old cookbooks is seeing them in their original format with their original font and other formatting intact, warts and all. That’s what elicits “I remember that ad!” comments for the newer ones, and evokes a sense of history for all of them.

The Baker’s Dozen is a perfect example of that. The recipes are good—often great—but the overall effect would not be nearly as interesting without the mid-seventies photo and advertising style.

Swift, using PDFDocument and PDFPage can easily create a PDF from a series of images. Which I’ve never done because it’s almost as easy to just drag the series of images into an empty Preview document and save that as a PDF file.

Neither method of creating a PDF adds any ability to search them. It would be nice to both maintain the original formatting and add the ability to quickly navigate the document, either through a table of contents—something easily created using PDFDocument and PDFOutline in PDFKit—or by searching the text. Or, better yet, both.

Mouse is yellow: might want to plug it in when you’re done working today.

Keyboard yellow, mouse red: definitely plug it in when you’re done working.

The notification from macOS that a mouse battery is running low usually comes too late and at inopportune times. When it happens I soon need to stop everything or get a USB mouse somewhere.

What I usually end up doing is taking an unplanned break for a few minutes to get the mouse battery back up to a safe level, and then go back to work. And forget to plug it in for the long term when I’m done working.

It would be nice if I could customize the warning to happen earlier and be both obvious and unobtrusive when it does happen. GeekTool is perfect for obvious and unobtrusive. All I need is a script to generate the text to display and it will show up on the desktop, and only when it needs to.

If you always want to see the battery level of all battery-operated devices, use ~/bin/batteries. In GeekTool (or on the command line) you can add the --colors switch to display different levels with different colors; there is a warning level set to yellow, a critical level set to red, and anything else is green.

I’ve set the warnings to start at 30%, with critical explicitly at half that. I may change my mind later.

Using the actual color names—green, yellow, and red—requires that you have Term::ANSIColor installed. If you don’t, you can replace those codes with the actual color escape sequences:

If you only want to see the battery level of devices at or below the warning level, use ~/bin/batteries --warnings with or without --colors.

If you want to see devices that are charging, even if they’re above the warning level, add --wired to the command line.