{
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)
*
* 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