Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

pudge (1)

pudge
  (email not shown publicly)
http://pudge.net/
AOL IM: Crimethnk (Add Buddy, Send Message)

I run this joint, see?

Journal of pudge (1)

Wednesday August 14, 2002
10:08 AM

Fun with Mac OS X Preferences

[ #7090 ]

Mac OS still uses Internet Config to some extent, but it is different than in Mac OS 9 in a few ways. First, there's no UI to edit all of the fields; so if you want to edit something, and it's not provided in the Internet prefs box, you're sorta out of luck. Second, it doesn't use the same file format; it uses the XML plist format.

So my problem is that in Eudora, I like using ProFont ("Programmer's Font", similar to Monaco, but easier to read for code at small point sizes) for messages, but I check Eudora's prefs to use Internet Config (for SMTP host etc.), and there's no way to change the default screen font from Monaco to ProFont.

One solution might be to port Mac::InternetConfig, and use the API. But I tried something else.

I opened /Users/pudge/Library/Preferences/com.apple.internetconfig.plist -- an XML file -- and poked around. Nothing in there for ScreenFont, the pref I want to set. I poke around a little more to figure out how to add it if I want to. A standard entry looks something like:

            <key>WebBackgroundColour</key>
            <dict>
                <key>ic-data</key>
                <data>
                ////////
                </data>
            </dict>

OK, so what's the data? It looks suspiciously familiar. The first line of the XML file, after the declaration, is:

<!DOCTYPE plist SYSTEM "file://localhost/System/Library/DTDs/PropertyList.dtd">

OK, so that file tells us:

<!ELEMENT data (#PCDATA)> <!-- Contents interpreted as Base-64 encoded -->

Nice. Sure enough:

% perl -MMIME::Base64 -le 'print ord decode_base64(shift)' ////////
255

OK, so now I just need to get the data for ScreenFont, in the right format, then encode it in Base64. MacPerl to the rescue!

#!perl -wl
use MIME::Base64;
use Mac::InternetConfig;
print encode_base64($RawInternetConfig{kICScreenFont()});

%InternetConfig gives a sane human-readable value (in this case, ProFont). But %RawInternetConfig provides the raw packed data. I encode it and print it out:

AAkAAAdQcm9Gb250AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/////wAAAAA4W4tIAA2QVAAi
WYgD hACj97QAAAAiWYgAMzACAAAAAgCmiLIADt6oAA7enGj/90AApoirAAAAAAAID0xURVhUdHR4
dAANkF SIhAAiZJgDAwCj97QAAAAiZJ4AAAAAAAgAotoAAIEAAAAAAADMzMzMzMzMzACmiLpAnfFQ
AKLTKAAi VlL///8AACJWQkCJXpYAotqg////AAAiVkI=

So I reformat it a bit to have the same line lengths as the other entries in the file, and end up with:

            <dict>
                <key>ic-data</key>
                <data>
                AAkAAAdQcm9Gb250AAAAAAAAAAAAAAAAAAAAAAAAAAAA
                AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
                AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////
                /wAAAAA4W4tIAA2QVAAiWYgDhACj97QAAAAiWYgAMzAC
                AAAAAgCmiLIADt6oAA7enGj/90AApoirAAAAAAAID0xU
                RVhUdHR4dAANkFSIhAAiZJgDAwCj97QAAAAiZJ4AAAAA
                AAgAotoAAIEAAAAAAADMzMzMzMzMzACmiLpAnfFQAKLT
                KAAiVlL///8AACJWQkCJXpYAotqg////AAAiVkI=
                </data>
            </dict>

I quit Eudora, save the plist file, and reopen Eudora, and there it is as my new screen font: ProFont, size 9.

Yay!

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • You have something against the Property List editor [macaddict.com]? :-)

    --Nat

    • I don't need it, first of all. I also use command-line utilties for dealing with NetInfo.

      However, it would be harder in this case, IMO, to use it. This is the particular data:

      \0 \0\0ProFont\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0\0\0\0\0\0\0\0\0\0ÿÿÿÿ\0\0\0\08[‹H\0
      T\0"Yˆ„\0£÷´\0\0\0"Yˆ\030\0\0\0\0

  • I wonder why they base-64 encoded it, instead of just &-escaping it. You know, &#0; to &255;. Not very compact, but then if they wanted compact, they wouldn't be using XML.

    Maybe they just wanted to be able to have free whitespace, which I presume you can have in Base-64 but not if you're relying on &-encoding.