Home
|
FAQ
|
Feedback
|
Licence
|
Updates
|
Mirrors
|
Keys
|
Links
|
Team
Download:
Stable
·
Snapshot
|
Docs
|
Changes
|
Wishlist
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.