ref: 3d4f276f1fabeea8a2d94e8a72db765f1dcc4316
parent: 37a0c1af6a8b6d4f9ab2ab2adb3218b44bc64a04
author: Simon Tatham <anakin@pobox.com>
date: Wed Apr 27 15:44:34 EDT 2005
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]
--- a/gtk.c
+++ b/gtk.c
@@ -219,10 +219,23 @@
{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;
--- a/solo.c
+++ b/solo.c
@@ -3,10 +3,6 @@
*
* 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
@@ -13,10 +9,6 @@
* 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