Andrew Ho Résumé FormatsYou are here: Andrew Ho > Work > Résumé > Formats You can download my résumé in several different formats. The PDF version is typically the most convenient. You may need Adobe Acrobat Reader or xpdf to read it. To read Postscript files, you may need to download Aladdin Ghostscript along with GSView or GV. The HTML version uses cascading style sheets; reasonably recent versions of Mozilla, Internet Explorer, Netscape Navigator, or Lynx will parse it. Source CodeTo keep content synchronized, the different output formats above are all generated from a common XML source file. An object-oriented, dispatch-table based interface on top of the Perl XML::Parser module available from CPAN parses the XML source code to produce LaTeX source, HTML, and text output. The LaTeX source is then processed by LaTeX2e (from the teTeX distribution) and dvips. The Postscript output incorporates the high-quality Type 1 Computer Modern fonts disseminated by the AMS. PDF hyperlinks are added through the hyperref package (see the HyperTeX FAQ for details). The PDF version is then produced and optimized with Adobe Acrobat software. GeneratorThe generator program which compiles XML to the various output formats has several components. Resume.pm is Perl module which implements a subclass of XML::Parser (which you may need to download from CPAN). It provides a dispatch-table interface to each XML element, which doesn't scale well, but makes building components incredibly easy. The resume script then pulls in the dispatch table code and associated subroutines from one of three Perl libraries (latex.pl, html.pl, and text.pl, for the LaTeX, HTML, and text output, respectively) and outputs finished code/text to STDOUT. A Makefile automates the build process. HindsightThe bulk of this code was originally written in 2000, and was my first experience with parsing XML. If I were to write my résumé from scratch today, I'd probably use XSLT stylesheets to solve this problem (probably still with a final custom HTML to text conversion step, as XSLT doesn't really solve the old-fashioned text justification problem). Another possibility would be to continue doing my own parsing—I enjoy writing state machine based XML parsers—and use a Perl template system for the output. This mirrors a lot of the web backend work I have done. XML isn't very fashionable these days, but it's actually not a bad choice for this particular use case (I think better than Markdown or YAML or s-expressions). I suppose I would reimplement it in Ruby nowadays. In any case, though, the bulk of the work would be to reproduce the painstakingly crafted templates themselves, and rewriting these doesn't seem justified at the moment. It's certainly been a long time since I've done much LaTeX hacking! Perhaps when I'm hunting for a job in earnest, I'll redo everything and package it up. |