crazed monkey

Creating PDFs is difficult. Creating PDFs for print is even more difficult. Reportlab does a great job, but it defaults to RGB in most cases. This necessitates some tweaking of both Reportlab code and the code using Reportlab. Testing the result is difficult, mostly because I don’t know of any command-line tools to do preflight testing for RGB and CMYK elements.

What I need is a command-line tool to do some basic PDF preflighting (eg. non-CMYK elements, non-embedded fonts, images below 300dpi, characters which may cause difficulties in printing, etc.). Is that so much to ask? When the PDF spec is 1300 pages long, it is. Still, don’t think I won’t try and take a stab at it.

Posted on February 27th, 2008 in programming - No Comments »

On Monday individuals from the four websites who collected TTC website suggestions from the Toronto community through their weblogs released their findings to the TTC and the general public. They did so in the worst way possible; using a spreadsheet. These are four fairly successful websites, all running popular weblogs and collecting their suggestions from local web users in their comments sections, also on the web. Wouldn’t it have made sense to also release their findings on, oh I don’t know, a web page? Apparently that would have made way too much sense.

Let’s ignore that not everyone has Microsoft Excel on their machines. (I don’t and instead had to wait for that ugly behemoth, NeoOffice, to sputter to life and display the data.) Let’s also ignore that if a spreadsheet was the answer, it could have been released in CSV format. Instead, let’s look at the data. (Those of you without Microsoft Excel will have to follow along using the image below.)

The open letter to Adam Giambrone describes the spreadsheet as “easy to use”. When you say something is easy to use, it had damn well better be. Personally, I had to stare at the spreadsheet for a few minutes before I could make heads or tails of it. Describing something as easy to use when it isn’t has the adverse effect of making anyone who doesn’t find it intuitive feel like an idiot.

First, the data is not a table and the first column seems to have absolutely no relation to the matching rows in the other columns. I have no idea what that first column is supposed to represent. Is it the cities from which the comments originated? Who knows.

Second, the acronyms and numbers you see (SPC 3, RT 4, etc.) are supposed to describe the website and comment number which made the suggestion in that column. There’s no legend, so I can only assume that “TI” means Torontoist.com and “RT” means Reading Toronto, “SPC” means Spacing and “BT” means blogTO. No website addresses or comment URLs are given so when this spreadsheet is printed or passed around the internals of the TTC, nobody will know what the heck those letters and numbers mean and won’t know where to go for more information.

Third, the spreadsheet isn’t even using spreadsheet functionality. It’s a table, but it’s not. The comment references are comma-separated across multiple rows, so there’s no way to do anything meaningful with this data such as sum the columns and graph the results, which is what everyone wants to do with spreadsheets. To find comment totals, you will have to manually count the references.

Fourth, you can’t see it from the image but my website is misspelled in row 22. It’s crazedmonkey.com, not crazymonkey.com. Thanks, guys.

Fifth, many of the comments referenced do not match the feature under which they appear (eg. TI 23 under the independent server suggestion). Also, RT 14 does not exist.

How would I have captured the website findings? First, I wouldn’t have made the mistake to release it in spreadsheet form. Instead, a simple HTML page would do the trick. The data can be expressed as a list using CSS styling wherever appropriate:

<ol>
  <li>Suggestion 1
    <ul>
      <li><a href=”link to comment”>website and comment author or number</a></li>
      …
    </ul>
  </li>
  …
</ol>

With the above format, every comment has a link to check. The file or link can still be passed around with no loss of information.

All of this begs the question, why even bother with a findings document at all? The comments are in an open forum which everyone can read and from which they can draw their own conclusions. Releasing a difficult to understand requirements document does nothing to help, but actually serves to inhibit. Who is going to take seriously anyone who creates a spreadsheet like that and passes it off as helpful? It’s well-intentioned but there’s a reason why the requirements gathering process, particularly in the software and usability fields, is left to the experts, or at least those with domain experience.

Update: I have since remixed the suggestion matrix into a HTML page as described above.

Posted on January 24th, 2007 in programming, ttc - 5 Comments »

When I released my new Toronto transit map I promised to release some of the tools I used to create it. Possibly the most useful tool I created is my command-line tile cutter. True, there are other image tilers, such as a Photoshop script and a web-based tool which uses Google Maps. I don’t have Photoshop and find it slow, and the web-based tool is difficult to use even with small files, so I created my own tile cutter.

My image tiler uses Free Software, is released under the GPL, and has the following features:

• Tiles most image formats, including GIF, JPEG, PNG and TIFF.
• Works on most flavours of Unix, including Mac OS X.
• Supports version 1 and version 2 zoom levels.
• Automatically calculates offsets for all zoom levels.
• Supports padding from the upper-left as output by the web-based tiling helper.
• Automatically pads image to size appropriate to Google Maps (ie. multiple of 256).
• Optionally discards empty transparent tiles to save space.
• Optional prefix for each tile.
• Outputs tiles in PNG format.
• Compresses tiles with either advpng or pngcrush.

The tiler requires ImageMagick and advpng or pngcrush for PNG compression. (I recommend advpng as it is faster and compresses smaller in most situations.) Tiled image size is restricted only by disk space and ImageMagick limitations.

To use the tile cutter, one need only specify the image being tiled, the Google tile coordinates of the top-left tile, the zoom level for which those coordinates are valid and the zoom level the tile represents. For example, suppose we have three images (img15.png, img16.png and img17.png) for zoom levels 15 through 17 (in version 2 zoom levels), respectively. The top-left corner of the image at level 15 is 1812,1924. You would then run the following commands to generate the tiles:

% googletilecutter -o 15 -t 1812,1924 -z 15 img15.png
% googletilecutter -o 15 -t 1812,1924 -z 16 img16.png
% googletilecutter -o 15 -t 1812,1924 -z 17 img17.png

Note that the only options which need to be changed from image to image are the zoom level of the image and the image itself. Compression and discarding of empty tiles is performed automatically. For more command-line options execute the script with the -h option.

Download the Unix command-line tile cutter for Google Maps. If you have any problems or experience any unexpected behaviour, please leave a comment below.

Posted on January 24th, 2007 in googletilecutter, programming - 14 Comments »

It’s not very well documented, but it’s possible to include multiple conditional expressions in a single if statement in BASH. By multiple conditional expressions, I mean something like:

if foo = 1 or bar = 3 or abc = 4 then
    print Hello World
end if

You can do boolean OR in BASH by using the -o operator. The following is the above code written in BASH:

if [ $foo -eq 1 -o $bar -eq 3 -o $abc -eq 4 ]; then
    echo Hello World
fi

For boolean AND, use the -a operator. You can also intermix the two.

Posted on November 21st, 2006 in programming - 8 Comments »

Here I was thinking that my old TTC map was only helping a few dozen people a day. In goes my updated map and up go my visits by several hundred per day. It turns out that I was closing the Google Analytics script tag in the XML style (ie. <script .../>) and not as <script ...></script>. The culprit? IE, of course, which doesn’t support the former.

Posted on November 13th, 2006 in programming, site - No Comments »