diff options
| -rw-r--r-- | gtk.c | 15 | ||||
| -rw-r--r-- | solo.c | 8 |
2 files changed, 14 insertions, 9 deletions
@@ -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) @@ -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 |