I have had cause to write a lot of Google Docs recently, which leaves me furnished with a stock of interesting observations that others might find helpful. With no further ado…
I typically want my business-like docs to have numbered headings, so an H3 might be “2.4.1. Architecture considerations”. Word can just do this automatically and keep them up to date with the changing structure of your doc. Google Docs can’t, though there is a free add-on called “Table of contents” which performs a dual duty here:
Rather surprisingly, the add-on can be very slow indeed to do its thing – even clicking on a link often took 3+ seconds to actually jump to the location in a 27 page doc. This is hard to fathom, but most docs are fairly short and it behaves acceptably well. Add-ons are trivially easy to install – just go to the Add-ons menu in your doc – so I would recommend everyone to dive in. Once you have used this particular add-on once, it’s two clicks to turn it on for any doc from the menu.
In Safari when you hit cmd-P to print, nothing happens. This leaves you a little bewildered, so you try again, and then you try invoking the menu item with the mouse rather than using the keyboard shortcut. A few seconds after the initial attempt, you might notice a little icon swoop up to the downloads button in the Safari toolbar – and when you click up there to check you’ll find each of your print attempts have caused it to download a PDF of the doc, after a multi-second wait in each case, naturally. Then you curse, open the PDF in Preview and print it from there.
I suspect it’s a lot better in Chrome, but for my money there’s no excusing such a poor experience in Safari. At the very least it should give feedback to show that it’s received your request to print and is working on it, and then make it clear what it’s actually done.
I wanted to include a landscape format diagram on its own page. Tough – all pages in the doc must be the same orientation.
This is a trivial little thing, but annoying: if I paste a table (of estimates breakdowns, say) from a Google Spreadsheet into a Google Doc, it drops some of the text alignment formatting – so cells that were left-aligned become right-aligned.
Really it’s a shame I can’t embed a Spreadsheet directly in the doc, especially where I just want to get totals added up for me.
Then again, I always found Word rather wanting in handling appendices nicely.
I was shocked and dismayed (again) to see no gradients in Google Drawings. The whole story of these apps seems to be excruciating simplicity, which is great in a way, but the reluctance to gradually increase the feature set puzzles me when they’re genuinely trying to compete with Word.
In one case I resorted to rolling my own gradients by duplicating and offsetting a shape repeatedly with very low opacity (so the opacities gradually stack up), then grouping the results. You only want to try this in extreme circumstances where it’s really important to you.
All of those irritations aside, it’s still my go-to tool for bashing out docs, partly because I don’t have Word and am not in a hurry to acquire it. Learn the keyboard shortcuts, use the Table of contents add-on, and you can be quite effective. I suppose the simplicity may even help to concentrate on the content and structure.
That said, an online editor that had the same cloud storage, collaboration and a much improved feature set, would be a big draw. Frankly it’s probably out there if only I look, but Google have done just enough to grab and retain the market.
Over the last little while, I’ve started to suffer from lack of space on the hard disk in my laptop, which is ridiculous, since there’s an 80GB disk in there and there is no way I have that much data I need to hang on to. I decided to do something about it last week. The main part of the problem was to figure out what was eating all the space:
du tells you exactly what’s using how much, but it’s hard to get a feel for where your space has gone by scanning through pages of
du output. So I built a program to help.
spaceviz is a small Python program that takes the output of
du -ak, and builds you a picture and HTML client-side imagemap of your space usage
Running it against the output of
du -ak / showed me very clearly where all the space had gone: not only did I have a few seasons of various TV shows on my disk (which I already knew were there), but I had 11 GB of unneeded gzipped RDF data left over from a project that finished earlier this year (that I had forgotten about). Instant win!
To run it for yourself, check out the mercurial repository
http://hg.opensource.lshift.net/spaceviz, and run
make veryclean all ROOT=/
ROOT=/ with a definition of
ROOT that points at the directory tree you want to generate usage data for. The makefile will take care of running
spaceviz.py for you. Edit the settings for
spaceviz.py to change the dimensions of the generated picture.
The program runs not only on Linux without fuss, but also on OS X so long as you have the
netpbm port installed to convert the python-generated PPM file to a browser-accessible (and much more efficiently compressed!) PNG.
GNU Smalltalk version 2.95h (the latest release candidate) didn’t compile out-of-the-box on Mac OS X 10.3.9 for me. The two changes that were required were:
* change the header file includes in
socketx.h to the older way of getting the prototypes for
* change part of a
.section declaration in
darwin\_closure.S to remove mention of the
live\_support section attribute.
After these changes, gst compiles and runs well for me on my OS X 10.3.9 box.
If you’ve upgraded to Leopard, and you’re an Emacs user, you may have found that typing emacs in a term no longer works — you get “Fatal malloc_jumpstart() error”. This will be the case if you’re using something like Fink or Darwin Ports, but it may also be the case if the upgrade didn’t quite work out.
The builds in Fink and Darwin Ports are currently broken; but otherwise, you have a few options to get Emacs back:
Use the Emacs that comes with Leopard. All this solution involves is making sure that any custom binary isn’t on the path — remove or move
/opt/local/bin/emacs (or possibly even
/usr/local/bin/emacs) and make sure
/usr/bin/emacs is the one installed with Leopard — /usr/bin/emacs --version should tell you the version is “22.1.1″.
The problem with the Emacs shipped with Leopard is that it’s built with no X support
(or Carbon, for that matter).
Use Aquamacs. Aquamacs has precompiled binaries which work with Leopard. But, beware, it is quite different from Emacs in some ways — if you used Emacs before you used MacOS X, you probably won’t like it.
Compile your own Emacs. This is what I did. The stock 22.1 source distribution won’t build in Leopard; it gives up the ghost with a message “Assertion failed: (filesize <= ranges->size)”. However there is an unofficial patch, which worked for me. I’m going to keep my custom emacs until fink or ports catches up.
In summary (adapted slightly from here):
curl -O http://ftp.gnu.org/pub/gnu/emacs/emacs-22.1.tar.gz tar xvzf emacs-22.1.tar.gz cd emacs-22.1 curl -O http://ephemera.continuation.org/patches/emacs-leopard-unexec.patch patch -p0 < emacs-leopard-unexec.patch ./configure --without-carbon --with-x --prefix=/usr/local make sudo make install
I put the result in
/usr/local and made sure
/usr/local/bin was on my path before any of the other possibilities, while I wait for Fink or Ports to catch up.
UPDATE: Thanks to masklinn's comment below, I can present another option which I'd overlooked:
Use carbonised Emacs. If you want to run Emacs in its own window, but don't want X11, there is a ready-made
.app wrapper in the source distribution. The disk image, which masklinn suggests, has patches and some very useful bundled Elisp packages, like nxml-mode.
You can also use the emacs distributed with Leopard with the .app wrapper, as jfb points out (see the second comment below); or, compile your own carbonised Emacs, similar to what I did above: change the configure invocation
./configure --with-carbon --without-x make cp -R mac/Emacs.app ./ cp src/emacs Emacs.app/Contents/MacOS/ sudo mv Emacs.app /Applications/
Either way gives you an Emacs that behaves like a MacOSX app and doesn't need X11 to run.
You are currently browsing the archives for the MacOSX category.