From 230d400ddc4e802b64b9664431c9429bfb4cfd66 Mon Sep 17 00:00:00 2001 From: Simon Tatham Date: Sat, 18 Nov 2006 15:10:48 +0000 Subject: [PATCH] Reinstate as much of the Windows font-linking behaviour as I can easily manage, by adopting a hybrid approach to Unicode text display. The old approach of simply calling ExtTextOutW provided font linking without us having to lift a finger, but didn't do the right thing when it came to bidirectional or Arabic-shaped text. Arabeyes' replacement exact_textout() supported the latter, but turned out to break the former (with no warning from the Windows API documentation, so it's not their fault). So now I've got a second wrapper layer called general_textout(), which splits the input string into substrings based on bidi character class. Any character liable to cause bidi or shaping behaviour if fed straight to ExtTextOutW is instead fed through Arabeyes' exact_textout(), but the rest is fed straight to ExtTextOutW as it used to be. The effect appears to be that font linking is restored for all characters _except_ Arabic and other bidi scripts, which means in particular that we are no longer in a state of regression over 0.57. (0.57 would have done font linking on Arabic as well, but would also have misbidied it, so we've merely exchanged one failure mode for another slightly less harmful one in that situation.) [originally from svn r6910] --- minibidi.c | 34 ++++++++++++++++++ putty.h | 1 + windows/window.c | 91 ++++++++++++++++++++++++++++++++++++++++++++---- 3 files changed, 120 insertions(+), 6 deletions(-) diff --git a/minibidi.c b/minibidi.c index c3581803..6219366b 100644 --- a/minibidi.c +++ b/minibidi.c @@ -877,6 +877,40 @@ unsigned char getType(int ch) return ON; } +/* + * Function exported to front ends to allow them to identify + * bidi-active characters (in case, for example, the platform's + * text display function can't conveniently be prevented from doing + * its own bidi and so special treatment is required for characters + * that would cause the bidi algorithm to activate). + * + * This function is passed a single Unicode code point, and returns + * nonzero if the presence of this code point can possibly cause + * the bidi algorithm to do any reordering. Thus, any string + * composed entirely of characters for which is_rtl() returns zero + * should be safe to pass to a bidi-active platform display + * function without fear. + * + * (is_rtl() must therefore also return true for any character + * which would be affected by Arabic shaping, but this isn't + * important because all such characters are right-to-left so it + * would have flagged them anyway.) + */ +int is_rtl(int c) +{ + /* + * After careful reading of the Unicode bidi algorithm (URL as + * given at the top of this file) I believe that the only + * character classes which can possibly cause trouble are R, + * AL, RLE and RLO. I think that any string containing no + * character in any of those classes will be displayed + * uniformly left-to-right by the Unicode bidi algorithm. + */ + const int mask = (1<left, lprc->top, lprc->right, lprc->bottom)); +debug(("\n")); +#endif + + xp = xn = x; + + for (i = 0; i < cbCount ;) { + int rtl = is_rtl(lpString[i]); + + xn += lpDx[i]; + + for (j = i+1; j < cbCount; j++) { + if (rtl != is_rtl(lpString[j])) + break; + xn += lpDx[j]; + } + + /* + * Now [i,j) indicates a maximal substring of lpString + * which should be displayed using the same textout + * function. + */ + if (rtl) { + newrc.left = lprc->left + xp - x; + newrc.right = lprc->left + xn - x; + newrc.top = lprc->top; + newrc.bottom = lprc->bottom; +#ifdef FIXME_REMOVE_BEFORE_CHECKIN +{ +int k; +debug((" exact_textout: %d,%d", xp, y)); +for(k=0;kleft + xp - x; + newrc.right = lprc->left + xn - x; + newrc.top = lprc->top; + newrc.bottom = lprc->bottom; + ExtTextOutW(hdc, xp, y, ETO_CLIPPED | (opaque ? ETO_OPAQUE : 0), + &newrc, lpString+i, j-i, lpDx+i); + } + + i = j; + xp = xn; + } + +#ifdef FIXME_REMOVE_BEFORE_CHECKIN +debug(("general_textout: done, xn=%d\n", xn)); +#endif + assert(xn - x == lprc->right - lprc->left); +} + /* * Initialise all the fonts we will need initially. There may be as many as * three or as few as one. The other (poentially) twentyone fonts are done @@ -3295,12 +3378,8 @@ void do_text_internal(Context ctx, int x, int y, wchar_t *text, int len, wbuf[i] = text[i]; /* print Glyphs as they are, without Windows' Shaping*/ - exact_textout(hdc, x, y - font_height * (lattr == LATTR_BOT) + text_adjust, - &line_box, wbuf, len, IpDx, !(attr & TATTR_COMBINING)); -/* ExtTextOutW(hdc, x, - y - font_height * (lattr == LATTR_BOT) + text_adjust, - ETO_CLIPPED | ETO_OPAQUE, &line_box, wbuf, len, IpDx); - */ + general_textout(hdc, x, y - font_height * (lattr == LATTR_BOT) + text_adjust, + &line_box, wbuf, len, IpDx, !(attr & TATTR_COMBINING)); /* And the shadow bold hack. */ if (bold_mode == BOLD_SHADOW && (attr & ATTR_BOLD)) {