Fix inconsistent vertical centring of text in GTK (and update Solo's
authorsimon <simon@cda61777-01e9-0310-a592-d414129be87e>
Wed, 27 Apr 2005 19:44:34 +0000 (19:44 +0000)
committersimon <simon@cda61777-01e9-0310-a592-d414129be87e>
Wed, 27 Apr 2005 19:44:34 +0000 (19:44 +0000)
todo list, which complained about this because Solo was the only
puzzle noticeably affected).

git-svn-id: svn://svn.tartarus.org/sgt/puzzles@5694 cda61777-01e9-0310-a592-d414129be87e

gtk.c
solo.c

diff --git a/gtk.c b/gtk.c
index 1a74d87..5690eae 100644 (file)
--- a/gtk.c
+++ b/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)
diff --git a/solo.c b/solo.c
index 0f3400c..87f1e74 100644 (file)
--- a/solo.c
+++ b/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