Type

My new favorite programming font


I have a hate/tolerate relationship with so-called “programmer’s fonts”. Let me count the ways they suck, in no particular order:

  1. Not fixed-width. Blech.
  2. Too-narrow set width (ranging between condensed and crushed).
  3. Inconsistent weight/color between alpha, numeric, and punctuation. The creator of Fira Code actually managed to make \ and / different weights!
  4. Twee punctuation.
  5. Failure to adequately distinguish 0O, l1, etc.
  6. Dotted zero instead of slashed (so that 00 is staring at you; Hack takes this one step further, for an Eye-Of-Sauron effect).
  7. Inconsistent centerline for special chars (^>~*+=-})]|\/#$%&@).
  8. Special-char centerline inconsistent with digits.
  9. - not same length as + and = (surprisingly common!).
  10. Five-lobed asterisk, even worse when it’s upside-down.
  11. Poor rendering either on or off high-DPI displays.
  12. Special Dishonorable Mention to Monofur for having lower-case digits, seemingly-random centerlines, twee punctuation, and a generally obnoxious character design.

For a long time, I’ve been using Anonymous Pro, hand-edited to fix its centerline problem, but the new winner is Office Code Pro, which suffers only from a slightly-twee %, a slightly-italic $, a five-lobed *, and an ever-so-slight centerline offset for braces, parens, and the v-bar (most easily seen in the -{| combo).

It is hands-down the cleanest, most usable fixed-width font I’ve ever found, fixing almost every problem with its parent, Adobe’s free Source Code Pro. Pity the repo just has the compiled fonts rather than the source diffs, because I’d love to fork it and fix those last few niggling flaws.

Installing fonts from the DynaFont collection


Let’s say that you have purchased a shovelware disc of Japanese fonts, such as this one from DynaComWare (discontinued, but it turns up occasionally; I bought mine at a going-out-of-business sale).

[Note that when I describe this particular disc as “shovelware”, I’m really referring to the collection of 3,000+ renamed ripoffs of Western fonts (from font pirate Bay Animation) that are thrown in; for Japanese, Chinese, and Korean fonts, DynaComWare is a legitimate foundry.]

The ripoffs (as well as the Korean, Chinese, special-effects, and kana fonts) are just stored on-disc with no protection, but the good stuff is hiding in files with the .t4 and .t9 extensions. The only supported way to install them is by running the included Windows program (which might not display correctly on non-Japanese versions of Windows, and of course doesn’t work at all on a Mac), but it turns out that they’re just encrypted ZIP files with a simple 8-digit numeric password, six digits of which can be inferred from the timestamp.

One thing to note is that the disc contains two sets of kanji fonts, in directories labeled JIS90 and JIS2004. The difference between the two is a subtle appearance change in a small number of characters, neatly described in this Adobe PDF file. A small number of fonts are available only in the JIS90 flavor, mostly pseudo-bitmap fonts of little real value; most people won’t notice the difference, and if you do, well, you’ve got both.

I highly recommend the disc, by the way.

Anonymous Pro (still) FTW!


Adobe has released an Open Source coding font, appropriately named Source Code Pro. I tried it out, and while it’s mostly nice, a side-by-side comparison of the fixed-width fonts on my machine reconfirmed that the also-free Anonymous Pro still beats them all.

Of course, if you don’t write Perl, you might not need expressions like “$K[$i%@K]” to look good, but I still can’t be comfortable with any font where “00” looks like it’s staring at you…

And my test sample, if you’re interested, consisted of Andale Mono, Anonymous Pro, Consolas, Courier, Inconsolata, Monaco, Osaka, and Lucida Sans Typewriter.

Custom font mappings in World Tools Pro


World Tools Pro enables most of the hidden Japanese typography functionality in InDesign, but as I discovered the moment I tried to really use it, they left out the ability to add custom ranges to composite fonts. The fix is to create the composite font as usual, then open the Adobe ExtendScript Toolkit, paste in the following snippet of code, edit as needed, and run it:

app.compositeFonts.item(1).compositeFontEntries.add({
    name:"Macron",
    customCharacters:"āĀēĒīĪōŌūŪ",
    appliedFont:"Minion Pro",
    fontStyle:"Regular",
    relativeSize:100,
    baselineShift:0,
    verticalScale:100,
    horizontalScale:100,
    scaleOption:false
  });

Set the value of item() based on font’s position in the pulldown list; the meaning of the rest should be obvious.

White-on-gray


Q: What happens when you print white text on a black background?

A: The black ink bleeds into the letters, making them thinner and obscuring fine details. The extent of this problem depends on the specific printing technology, but a good rule of thumb is to use bolder fonts when you do white-on-black.

Q: What happens when you print white kanji, really small, on a light gray background that’s constructed as a color halftone?

A: Garbage.

more...

Automating PDF cleanup with Acrobat and AppleScript


As I mentioned earlier, I’m generating lots of PDF files that don’t work in Preview.app, and are also a tad on the large side. Resolving this problem requires the use of Adobe Acrobat and Acrobat Distiller. Automating this solution requires AppleScript. AppleScript is evil.

Just in case anyone else wants to do something like this from the command line, here’s what I ended up with, which is run as “osascript pdfcleaner.scpt myfile.pdf”:

on run argv
    set input to POSIX file ((system attribute "PWD") & "/" & (item 1 of argv))
    set output to replace_chars(input as string, ".pdf", ".ps")
    
    tell application "Adobe Acrobat 7.0 Standard"
        activate
        open alias input
        save the first document to file output using PostScript Conversion
        close all docs saving no
    end tell
    
    tell application "Acrobat Distiller 7.0"
        Distill sourcePath POSIX path of output
    end tell
    
    set nullCh to ASCII character 0
    set nullFourCharCode to nullCh & nullCh & nullCh & nullCh
    tell application "Finder"
        set file type of input to nullFourCharCode
        set creator type of input to nullFourCharCode
    end tell
    
    tell application "Terminal"
        activate
    end tell
end run
    
on replace_chars(this_text, search_string, replacement_string)
    set AppleScript's text item delimiters to the search_string
    set the item_list to every text item of this_text
    set AppleScript's text item delimiters to the replacement_string
    set this_text to the item_list as string
    set AppleScript's text item delimiters to ""
    return this_text
end replace_chars

[I wiped out the file type and creator code to make sure that the resulting PDFs opened by default with Preview.app, not Acrobat; I swiped that code from Daring Fireball. The string-replace function came from Apple’s AppleScript sample site.]

PDF::API2, Preview.app, kanji fonts, and me


I’d love to know why this PDF file displays its text correctly in Acrobat Reader, but not in Preview.app (compare to this one, which does). Admittedly, the application generating it is including the entire font, not just the subset containing the characters used (which is why it’s so bloody huge), but it’s a perfectly reasonable thing to do in PDF. A bit rude to the bandwidth-impaired, perhaps, but nothing more.

While I’m on the subject of flaws in Preview.app, let me point out two more. One that first shipped with Tiger is the insistence on displaying and printing Aqua data-entry fields in PDF files containing Acrobat forms, even when no data has been entered. Compare and contrast with Acrobat, which only displays the field boundaries while that field has focus. Result? Any page element that overlaps a data-entry field is obscured, making it impossible to view or print the blank form. How bad could it be? This bad (I’ll have to make a screenshot for the non-Preview.app users…).

The other problem is something I didn’t know about until yesterday (warning: long digression ahead). I’ve known for some time that only certain kanji fonts will appear in Preview.app when I generate PDFs with PDF::API2 (specifically, Kozuka Mincho Pro and Ricoh Seikaisho), but for a while I was willing to work with that limitation. Yesterday, however, I broke down and bought a copy of the OpenType version of DynaFont’s Kyokasho, specifically to use it in my kanji writing practice. As I sort-of expected, it didn’t work.

[Why buy this font, which wasn’t cheap? Mincho is a Chinese style used in books, magazines, etc; it doesn’t show strokes the way you’d write them by hand. Kaisho is a woodblock style that shows strokes clearly, but they’re not always the same strokes. Kyoukasho is the official style used to teach kanji writing in primary-school textbooks in Japan. (I’d link to the nice page at sci.lang.japan FAQ that shows all of them at once, but it’s not there any more, and several of the new pages are just editing stubs; I’ll have to make a sample later)]

Anyway, what I discovered was that if you open the un-Preview-able PDF in the full version of Adobe Acrobat, save it as PostScript, and then let Preview.app convert it back to PDF, not only does it work (see?), the file size has gone from 4.2 megabytes to 25 kilobytes. And it only takes a few seconds to perform this pair of conversions.

Wouldn’t it be great to automate this task using something like AppleScript? Yes, it would. Unfortunately, Preview.app is not scriptable. Thanks, guys. Fortunately, Acrobat Distiller is scriptable and just as fast.

On the subject of “why I’m doing this in the first place,” I’ve decided that the only useful order to learn new kanji in is the order they’re used in the textbooks I’m stuck with for the next four quarters. The authors don’t seem to have any sensible reasons for the order they’ve chosen, but they average 37 new kanji per lesson, so at least they’re keeping track. Since no one else uses the same order, and the textbooks provide no support for actually learning kanji, I have to roll my own.

There are three Perl scripts involved, which I’ll clean up and post eventually: the first reads a bunch of vocabulary lists and figures out which kanji are new to each lesson, sorted by stroke count and dictionary order; the second prints out the practice PDF files; the third is for vocabulary flashcards, which I posted a while back. I’ve already gone through the first two lessons with the Kaisho font, but I’m switching to the Kyoukasho now that I’ve got it working.

Putting it all together, my study sessions look like this. For each new kanji, look it up in The Kanji Learner’s Dictionary to get the stroke order, readings, and meaning; trace the Kyoukasho sample several times while mumbling the readings; write it out 15 more times on standard grid paper; write out all the readings on the same grid paper, with on-yomi in katakana and kun-yomi in hiragana, so that I practice both. When I finish all the kanji in a lesson, I write out all of the vocabulary words as well as the lesson’s sample conversation. Lather, rinse, repeat.

My minimum goal is to catch up on everything we used in the previous two quarters (~300 kanji), and then keep up with each lesson as I go through them in class. My stretch goal is to get through all of the kanji in the textbooks by the end of the summer (~1000), giving me an irregular but reasonably large working set, and probably the clearest handwriting I’ve ever had. :-)

Dear Adobe,


While preparing a faithful, high-resolution copy of the Mac OS X kernel-panic screen (to submit a patch to XScreenSaver’s BSOD module, now that JWZ has gotten it mostly working as a native Mac screen-saver), I ran into several problems. First, the result of my efforts:

Mac OS X 10.3-10.4 kernel panic screen

Now for the problems. I started out working in Photoshop, mostly because I hate Illustrator and wish CorelDRAW 4 had been stabilized and ported to every useful platform, but quickly gave up. Even for a simple graphic like this, it’s just annoying to work without real drawing tools.

The power button took about fifteen seconds in Illustrator, leaving me to concentrate on the text (12.2/14.6pt Lucida Grande Bold and 13/14.6pt Osaka, by the way). The Japanese version took the longest, obviously, especially with the JPEG artifacts in my source image.

Mind you, the above PNG file wasn’t exported from Illustrator, because all of my attempts looked like crap. The anti-aliasing made the text too fuzzy. To produce a smooth background image with crisp text, I had to manually transfer the two layers to Photoshop. I exported the background graphic at 300dpi without anti-aliasing, resized it in Photoshop using the Bicubic Sharper mode, then created a text field, pasted in the text, set the anti-aliasing mode to Sharp, and nudged it into the correct position.

The real fun came when I wanted to take the text I’d so painstakingly entered and paste it into another application.

I couldn’t.

Selecting the text in Illustrator CS2 and copying it left me with something that could only be pasted into Photoshop or InDesign. Fortunately, InDesign was written by people who think that text is useful, and after pasting it there I could copy it again, ending up with something that other applications understood. See?

You need to restart your computer. Hold down the Power button for several seconds or press the Restart Button.

Veuillez redémarrer votre ordinateur. Maintenez la touche de démarrage enfoncée pendant plusieurs secondes ou bien appuyez sur le bouton de réinitialisation.

Sie müssen Ihren Computer neu starten. Halten Sie dazu die Einschalttaste einige Sekunden gedrückt oder drücken Sie die Neustart-Taste.

コンピュータを再起動する必要があります。パワーボタンを数秒間押し続けるか、リセットボタンを押してください。