PuTTY bug font-overflow

summary: Fonts that overflow their character cells cause problems
class: bug: This is clearly an actual problem we want fixed.
difficulty: tricky: Needs many tuits.
priority: medium: This should be fixed one day.
fixed-in: 2004-12-18 (0.58) (0.59) (0.60) (0.61) (0.62)

There's a two-pronged problem with fonts whose characters overlap outside their designated rectangular cell.

Firstly, we don't deal well with this. Each string passed to do_text() is clipped to the rectangle it should be in; but within that string there's still scope for overlap between character cells. If half the string is then updated then there will be artefacts left on the screen. This seems to be particularly common when using ClearType in Windows XP.
Secondly, the resize-by-changing-font code has a tendency to choose fonts that cause this problem a lot. For bitmap fonts I think this is just a hazard of the job - if you ask PuTTY to resize a non- resizeable font, you can expect it to do a shoddy job at best - but it even happens slightly in Courier New (the very RH edge of the lower case m sometimes protrudes into the next character cell), which really isn't on. Sadly I have no idea how we can fix this in general - if we ask for a smaller width than we really want, then (a) we penalise well-behaved fonts, and (b) the spacing when drawing a large string will come out wrong.

Simon has a cunning idea for dealing with this. The plan is that whenever we paint a string on the screen, we clip it to its bounding rectangle (this should happen already), and then whenever we change the contents of the rectangle, we always re-paint the whole thing, splitting it into smaller rectangles, or joining rectangles together as appropriate. This way, we never leave droppings behind, because whenever a character is erased, the entire clipping box that was in force when it was painted is cleared as well. Unfortunately, implementing this is likely to involve substantial changes to the way PuTTY stores the contents of the screen.

SGT, 2004-12-17: I think this is now done. I've tested it in a known failure case on Windows (1600x1200 screen, set font to Courier New 11, set resize behaviour to change-font, maximise window, the lower case m then projects over its character cell) and it now appears not to cause any droppings no matter what I do.

Audit trail for this bug.

If you want to comment on this web site, see the Feedback page.
(last revision of this bug record was at 2004-12-17 12:55:12 +0000)