PuTTY bug win-font-linking

This is a mirror. Follow this link to find the primary PuTTY web site.

summary: Windows Unicode font linking broken
class: bug: This is clearly an actual problem we want fixed.
difficulty: tricky: Needs many tuits.
priority: high: This should be fixed in the next release.
absent-in: 0.56 0.57
present-in: 0.58
fixed-in: r6910 230d400ddc4e802b64b9664431c9429bfb4cfd66 2006-11-19 (0.59)

We've had one report that 0.58 breaks Windows' "font linking". This is a mechanism provided by vaguely modern Windows (by "Uniscribe/MLang", apparently) to transparently use multiple fonts as fallbacks to provide the best coverage of the vast Unicode space.

The symptom is that some Unicode characters that were correctly displayed in 0.57 will be displayed as blank spaces in 0.58. If those spaces are copied and pasted elsewhere, the original text will be recovered. Only characters that are actually in the current font will be displayed correctly.

This is likely a side-effect of the bidirectional and Arabic shaping changes. One of the first changes to support this was the creation of exact_textout(), which stops Windows from doing its own bidi/shaping transformations, so that we can do them ourselves. It looks like font linking is a casualty of this.

Suggestions for how to modify exact_textout() to allow font linking (and any other advanced rendering features we may have inadvertently clobbered) while preserving the properties we need would be most welcome.

Ben suggests another approach to defusing ExtTextOutW(): feed it Arabic presentation forms (which we do already) and also explicit Unicode directional overrides to force LTR rendering. (This does commit us to potentially having to find workarounds for any other cleverness that Windows' font engine might choose to impose on us.)

A workaround is to use a fixed-width font that directly supports all the characters you need, if you can find one.

SGT, 2006-11-18: I've just implemented an alternative workaround, which is to only use exact_textout() for those characters liable to cause unwanted bidi behaviour if passed straight to ExtTextOutW. So now everything other than right-to-left scripts is handled directly by ExtTextOutW, as it used to be, meaning that everything which 0.57 handled completely correctly should once again be handled completely correctly.

We still don't support font linking for bidi text, but this is no longer a regression over 0.57 because 0.57 would merely have done something else wrong when given bidi text.

If you want to comment on this web site, see the Feedback page.

Audit trail for this bug.

(last revision of this bug record was at 2017-04-28 16:52:45 +0100)