Fix inconsistent vertical centring of text in GTK (and update Solo's

todo list, which complained about this because Solo was the only
puzzle noticeably affected).

[originally from svn r5694]

gtk.c

@@ -219,11 +219,24 @@ void draw_text(frontend *fe, int x, int y, int fonttype, int fontsize,
     {
         int lb, rb, wid, asc, desc;
 
-        gdk_string_extents(fe->fonts[i].font, text,
+	/*
+	 * Measure vertical string extents with respect to the same
+	 * string always...
+	 */
+        gdk_string_extents(fe->fonts[i].font,
+			   "ABCDEFGHIJKLMNOPQRSTUVWXYZ",
                            &lb, &rb, &wid, &asc, &desc);
         if (align & ALIGN_VCENTRE)
             y += asc - (asc+desc)/2;
 
+	/*
+	 * ... but horizontal extents with respect to the provided
+	 * string. This means that multiple pieces of text centred
+	 * on the same y-coordinate don't have different baselines.
+	 */
+        gdk_string_extents(fe->fonts[i].font, text,
+                           &lb, &rb, &wid, &asc, &desc);
+
         if (align & ALIGN_HCENTRE)
             x -= wid / 2;
         else if (align & ALIGN_HRIGHT)

solo.c

@@ -3,20 +3,12 @@
  *
  * TODO:
  *
- *  - can we do anything about nasty centring of text in GTK? It
- *    seems to be taking ascenders/descenders into account when
- *    centring. Ick.
- *
  *  - it might still be nice to do some prioritisation on the
  *    removal of numbers from the grid
  *     + one possibility is to try to minimise the maximum number
  * 	 of filled squares in any block, which in particular ought
  * 	 to enforce never leaving a completely filled block in the
  * 	 puzzle as presented.
- *     + be careful of being too clever here, though, until after
- * 	 I've tried implementing difficulty levels. It's not
- * 	 impossible that those might impose much more important
- * 	 constraints on this process.
  *
  *  - alternative interface modes
  *     + sudoku.com's Windows program has a palette of possible