Adobe Acrobat can crop, of course, but it’s insane to shell out for the entirety of Acrobat when all you need is to crop a few PDFs now and then. There are a number of free shell scripts that do it, but the main one you’ll find, pdfcrop, requires perl to be installed, which it just ain’t on my Windows box here. I never use perl for anything these days, so I refuse to install it just so I can crop PDFs.

The basic functionality is there in the free GhostScript. Actually the pdfcrop script just serves as a little less terrible command-line UI for calling GhostScript. But for both of them you have to type in the number of units to crop on each side. So usually that means you get it wrong, adjust, get it slightly less wrong, adjust, lather, rinse, repeat. It’s ridiculous in this day and age.

This time searching I ran across something I hadn’t seen the previous nine times — pyPDF. A Python library for manipulating PDFs! Sounds good.  I actually use Python from time to time.  Unfortunately it was last updated in 2008, and when using the cropping recipe I found somewhere, it throws exceptions deep in pyPDF’s bowels (under Python 2.6.x).  So much for that.

So enough already. I’ve wasted so much time on this over the years that I’m actually willing to spend a reasonable amount of money to have a solution that “just works”. But I am not going to buy Acrobat just for this. Forget it.

So if I actually include reasonably priced utilities, what is out there?   I found one thing that seems to actually work pretty well, has visual cropping, and doesn’t cost a fortune. It’s a shareware called “A-PDF Page Crop“.  I’ve seen other crappy sharewares that actually just use the free GhostScript under the hood, and just try to convince you they did all the work.  That doesn’t look like the case here.  A-PDF has its own MMPDF.dll and no sign of a dependency on GhostScript that I can see.  If it’s there they’ve hidden it very well.   Anyway, the tool is easy to use and it actually works.  The price of $27 is not too bad, considering I’ve probably wasted at least 10 hours of my time over the years dinking around with pdfcrop, and searching the web for something better than pdfcrop.  What’s even better — they claim you can get a free license by blogging about them.  We’ll see how that pans out.  But either way, this looks like a decent tool, worth the price if you don’t have Acrobat and have an occasional need to crop PDF files.

It’s not exactly obvious, but it turns out that at least with WordPress blogs (like this one) you can subscribe to a particular category.

First you have to figure out the category number for the topic you’re interested in.  You can usually do that by clicking on the link for the category you’re interested in an looking at the url.  It’ll have part that says something like “cat=4″.   Then you append that onto the regular feed url.  Now you append that onto the base RSS url for the blog.  Like for this blog the base is:

http://www.billbaxter.com/techblog/wp-rss2.php

Use a “?” to tack on the category string and voila!

http://www.billbaxter.com/techblog/wp-rss2.php?cat=4

you have a category-specific feed url (in the case above, for my “code” topic, which current includes D, C++ and Python sub-categories.

Update: It seems WordPress folks changed the URL format they use at some point.  For the version I’m currently using (2.9.2), the format is now:

http://www.billbaxter.com/techblog/?feed=rss2&cat=4

The .php script referencing the type of feed is no longer explicit, and instead both feed type and category are just parameters.

So here are some category-links for my blog here (updated for my WP 2.9.2):

• D category
• C++ category
• Python category
• Code category
• Web category
• Math category
• Meta category (things about the blog itself)

I wrote that presentation for the Comp 290 physically based modelling grad course at UNC-Chapel Hill in the first or second year of my Masters/Ph.D.  It looks a little quaint to me now, but I’m pretty proud by how well it explains some things.  Maybe that’s only me, but anyway, some things like the intuition behind multi-dimensional non-linear optimization that I put in there have really stuck with me.

What really gets me tickled is that this class presentation has been the top hit for “fast inverse kinematics” ever since I wrote it lo these 8 years ago.

[edit]  I say it looks quaint because the problem is really a straight-up non-linear optimization problem, and the right way to tackle it is with a non-linear optimizer of some sort.  The CCD, Jacobian Transpose, and PseudoInverse methods are all just hacks in one way or other trying to avoid using a more apropriate optimization strategy.  IK problems all tend to be relatively low-dimensional, too, so for most apps the speed of a good robust optimizer would not be a problem.   Actually Nate’s blog there has some links to other more recent methods like Selectively Damped Least Squares for Inverse Kinematics.  Having done a lot of least squares stuff lately, some sort of non-linear least squares solution is what I’d try these days too.

Hooray!

Background for those who need it: in the world of the D programming language right now, there are two incompatible “standard” libraries.  The original Phobos library that ships with the DMD compiler, and the Tango project, a community-developed library that sprang up largely over dissatisfaction with the semi-closed and somewhat disorganized process of Phobos development.

This has really been a thorn in D’s side for a good while now — more than a year.  In a recent poll on the D newsgroup, this Phobos/Tango split was the #1 thing that people listed as needed fixing with D.  And finally it looks like it’s happening.  Happy day for D.

But enough grains of sand and you start to have a sizable obstacle. And D has a fair number of such grains. Pretty soon D needs to move out of feature triage mode and start working on polish, completing or cleaning up the features that do exist, and resolving issues with the tool chain. I thought that phase was about to begin now that const is basically settled, but now the goal posts seem to have moved again. Now it appears that cleanup won’t be a focus until until after the multicore problem is solved.  And given that multicore is not a solved problem in general, I think that could be a while.

Maybe the problem is just that Walter is not, and never will be, interested in working on small details. One can always find some new shiny holy grail feature on the horizon that’s more interesting to work on than, say, package visibility rules.  Features in D seem to get to the stage where they’re basically usable, then stagnate.  Like __traits, or like the non-overrideable $ in indexes (or rather overrideable only with the undocumented __dollar hack), or like associative arrays, or uniform call syntax that works only on built-in arrays.  If you’ve used D for any amount of time, I’m sure you’ve got your own favorite examples.  Language features in D never quite seem to reach that “insanely great” stage.

Here’s my pet theory about why that is so.  I think it comes down to dogfood.  Walter and the majority of the “D inner circle” basically don’t write code in D.  They spend their days writing C++, not D.  So shortcomings and annoyances in day-to-day D usage just don’t show up as major blips on the radar with these guys.   No associative array initializers?  Eh, no big deal, you can still initialize them in a loop.  So it’s not critical.  That’s easy to say, but when you’re the guy who actually has to write that loop, it starts to get annoying after the 10th time.  I think it’s universally recognized that to make great products it helps to eat your own dog food.  Unfortunately the core team working on D doesn’t.

With one exception — Andrei A. seems to have been writing a lot of D code.  And the result shows.  Things like fixing the limitation with IFTI came about directly because Andrei complained that it was too hard to write his libraries in the way they should be written with IFTI as it was.  Unfortunately I’m worried that Andrei’s influence in the D community will be drastically reduced now that he has left Seattle.  Walter seems to have trouble maintaining lines of communication when face-to-face meets at the coffee shop aren’t possible.

But back to dogfood.  In contrast to the core D folks, the Tango team seems to be deep in their own dogfood.  And really I think that right there explains the existence of Tango.   The Tango folks are actually using D and they got fed up trying to work with stuff that wasn’t built with that kind of in-the-trenches knowhow.

The current situation leaves me uneasy about D’s future.  How do we make sure D not only survives but becomes insanely great?  I have no silver bullet, but it seems to me like Walter is always going to be more interested in new and shiny than solid and complete.  That’s fine, really.  Somebody does need to be looking at the next big thing.  So I think what D really needs is a #2 guy who is both a heavy D user and a compiler writer and who’s main interest is making D polished.   I’m hoping that LLVMDC will somehow help there.  Lindquist and Kamm have been making great strides on that alternative D compiler, and have already proposed fixes for things like cross-module symbol visibility.  Hopefully they will be able to communicate effectively with Walter about these things, otherwise the ultimate result may be a forked language.  I know no one really wants that to happen, but it’s happened with the runtime already, and I don’t see any evidence that the environment that gave rise to that fork has significantly changed.

[update Sept 9, 2008]

Don’t count Andrei out of the running yet!  A day after I wrote the above, Andrei came out with a proposal for for iterators/ranges in D, what could become std.range for D2 Phobos.  What’s more, to implement it he has requested that Walter implement reference return values, and Walter has apparently agreed.  Well, this is exactly the kind of practical, day-to-day bread-and-butter programming stuff that D desperately needs.  Exactly the kind of polish and completeness issue I was talking about above.   The deficiencies of opApply and the lack of reference return values have long been on the top of my D peeves list.  So I’m really happy to see this development.  Maybe there’s still hope for D after all.

It’s a shame to let that effort go to waste without at least making a graph out of it.  So here it is:

Minimal D exe sizes over time

Yup, that’s a pretty big leap at the end.

Turns out PHP5.2 added “\f” as a special escape sequence.  So the php code that was working fine with LaTeX commands like “\formulabox” in double quoted strings, suddenly started breaking.  The \f’s became formfeeds, and what’s left (“ormulabox”, etc.)  was being interpreted by LaTeX as just regular words to put in the output.

So you could fix it by just turning those \f’s into \\f’s, but that would break latexrender on PHP4 installs.

So the fix to keep things working with both PHP4 or 5 is to put the bulk of those strings in single quotes.   So replace the wrap_formula function in wp-content/plugins/latexrender/class.latexrender.php with the following:

    function wrap_formula($latex_formula) {
        $string  = "\documentclass[".$this->_font_size."pt]{".$this->_latexclass."}\n";
        $string .= '\usepackage[latin1]{inputenc}' ."\n";
        $string .= '\usepackage{amsmath}' ."\n";
        $string .= '\usepackage{amsfonts}'."\n";
        $string .= '\usepackage{amssymb}'."\n";
        $string .= '\pagestyle{empty}' ."\n";
        $string .= '\newsavebox{\formulabox}' ."\n";
        $string .= '\newlength{\formulawidth}' ."\n";
        $string .= '\newlength{\formulaheight}' ."\n";
        $string .= '\newlength{\formuladepth}' ."\n";
        $string .= '\setlength{\topskip}{0pt}' ."\n";
        $string .= '\setlength{\parindent}{0pt}' ."\n";
        $string .= '\setlength{\abovedisplayskip}{0pt}' ."\n";
        $string .= '\setlength{\belowdisplayskip}{0pt}' ."\n";
        $string .= '\begin{lrbox}{\formulabox}' ."\n";
        $string .= "$\\ ".$latex_formula."$\n";
        $string .= '\end{lrbox}' ."\n";
        $string .= '\settowidth {\formulawidth}  {\usebox{\formulabox}}' ."\n";
        $string .= '\settoheight{\formulaheight} {\usebox{\formulabox}}' ."\n";
        $string .= '\settodepth {\formuladepth}  {\usebox{\formulabox}}' ."\n";
        $string .= '\newwrite\foo' ."\n";
        $string .= '\immediate\openout\foo=\jobname.depth' ."\n";
        $string .= '    \addtolength{\formuladepth} {1pt}' ."\n";
        $string .= '    \immediate\write\foo{\the\formuladepth}' ."\n";
        $string .= '\closeout\foo' ."\n";
        $string .= '\begin{document}' ."\n";
        $string .= '\usebox{\formulabox}' ."\n";
        $string .= '\end{document}' ."\n";

        return $string;
    }

And that does the trick.  This was a problem as of Aug 1, 2008, with version v0.8 of class.latexrender.php.