Re: Explicit LRO, RLO, etc. in FT2 patch

[Owen Taylor <otaylor redhat com>]

Tony Graham <Tony Graham ireland sun com> writes:

> With basic-ft2.c, formatting characters in the range U+202A to U+202E
> (i.e., bidi formatting characters LRE, RLE, LRO, RLO, and PDF) ends up 
> with Pango trying to find glyphs for the characters and failing.  The
> result is the .notdef "glyph" and a big gap in the line.
> 
> The following patch expands the list of characters that are
> effectively passed over as glyphs to include all non-graphic
> characters.
> 
> Regards,
> 
> 
> Tony Graham
> ------------------------------------------------------------------------
> Tony Graham                           mailto:tony graham ireland sun com
> Sun Microsystems Ireland Ltd                       Phone: +353 1 8199708
> Hamilton House, East Point Business Park, Dublin 3            x(70)19708
> 
> 
> Index: modules/basic/basic-ft2.c
> ===================================================================
> RCS file: /sgnome/cvsroots/GNOME/pango/modules/basic/basic-ft2.c,v
> retrieving revision 1.11
> diff -r1.11 basic-ft2.c
> 223c223
> <       if (wc == 0x200B || wc == 0x200E || wc == 0x200F)	/* Zero-width characters */
> ---
> >       if (!g_unichar_isprint (wc))	/* Zero-width characters */

Hmmm:

gboolean
g_unichar_isprint (gunichar c)
{
  int t = TYPE (c);
  return (t != G_UNICODE_CONTROL
	  && t != G_UNICODE_FORMAT
	  && t != G_UNICODE_UNASSIGNED
	  && t != G_UNICODE_PRIVATE_USE
	  && t != G_UNICODE_SURROGATE);
}

I think we should perhaps only exclude G_UNICODE_FORMAT here if
excluding classes of Unicode characters is the right
technique. Non-printed characters in the output stream are more
confusing than boxes or "unknown character" glyphs when the user
starts editing.

(Note that editing of directional formatting characters is something
we still haven't quite figured out how it should work.)

Regards,
                                        Owen