Scouting for the Pango change

[Cyrille Chepelov <cyrille chepelov org>]

Hello all, 

  I'm going to have a couple days of scheduled intense hacking (in dia and
other projects, like 'biking a couple hundreds of kcal out of my body') this
week-end. One of the things I would like to achieve is basic full-UTF-8 screen
I/O (Postscript will come in later), the goal being to be able to display
simultaneously a latin0 string and another string in a more exotic encoding,
all in the same window.

  Contrary to my habits, I plan to hang out on some specific #dia channel on
an irc network or another (will probably default to irc.debian.org), so the
session gets more fun (and, more brains for one problem can be a quite
useful thing).

  I've done some scouting ahead, on what will have to change. Here are my
temporary findings:

   * Calls to gdk_draw_string(....) for the gdk renderer become:        
        layout = gtk_widget_create_pango_layout(widget, text);
        gdk_draw_layout(drawable,gc,x,y,layout);
        g_object_unref (G_OBJECT (layout));

   * Calls to gdk_draw_string(....) for the Pixmap renderer become:
        context = gdk_pango_context_get()
        layout = pango_layout_new(context);
        gdk_draw_layout(pixmap,gc,x,y,layout);
        g_object_unref (G_OBJECT (layout));
        g_object_unref (G_OBJECT (context));

  In both these calls, we can let Pango handle the alignement/justification
  itself (instead of doing a manual compute), by setting the relevant
  attributes. It will also handle multiple lines. Of course, we can choose
  to do it 'manually', line-by-line, for the sake of consistency with PS 
  output.

   * Calls to gdk_text_width (and basically, font_string_width) become:
        context = gdk_pango_context_get(); // or pango_context_new() ??
                                           // see below
        layout = pango_layout_new(context); 
        gint ranges[2] = {0,strlen(str)};
        pango_layout_set_text(layout,str,ranges[1]);
        pango_layout_get_size(....) // beware the PANGO_SCALE
        g_object_unref(layout);
        // g_object_unref(context);

  * Benefits of using gdk_draw_layout():
        - the appropriate Pango back-end is selected automatically; on X
     it's either Xft (if available and compiled in) or X (fallback), and on
     Win32, it's (surprise) Win32. Xft does include FreeType2, plus some
     extra gizmos (especially for laptop users).

  * Problem with calling pango_context_new():
        - The context is useless until we call pango_context_new(). The font
        map can be retrieved only using back-end specific
        pango_XXX_font_map_for_display() calls.

        Bad news: at one point (rendering to bitmap formats, rendering to
        Postscript if we use Pango to break the text into nice, 
        scriptwise homogeneous runs of text), we WILL need to use the
        low-level pango_context_new() and back-end specific API.

  * With the crude way described above, we will basically be all the time
  building and destroying layouts (well, we can be "basically all the time
  calling pango_layout_set_text()" -- the problem is the same). Maybe this
  will be fast enough, maybe not. I'll bet on the fast thing, mostly because
  I want to be lazy.
 
  * Mouse clicks into text objects can be handled with 
  pango_layout_xy_to_index(). We have some, but not all help we want by
  using pango_layout_move_cursor_visually(). What the hell do they mean with
  strong/weak cursors, and "trailing edge of grapheme"? To move the cursor
  up/down, we'll need to inspect the Layout lines one-by-one and make good
  use of pango_layout_line_index_to_x() and pango_layout_line_x_to_index().

  It looks like we'll need to teach Text with the concept of a Pango Layout,
  and work from that. This also means we'll probably need to percolate the
  PangoLayout concept down to the Renderer as well (discriminated
  draw_string() and draw_layout() methods ?), since it would be wasteful to
  re-create a new layout in draw_string()... Or is it?

  * At one point, we might want to make a RichTextobj, so that it accepts 
  Pango markup... (for sanity's sake, I think the editor should be in a
  property page, multiline string)

  * Currently, input of non-ASCII characters into a Textobj results in 
  garbage; this garbage is consistently stored down to the XML file, which
  can not be subsequently read back by libxml (because some character runs
  are not valid UTF-8). text_key_event() probably needs some UTF-8 tune-up.

  * I have not seen anywhere any mention of being able to apply an angle
  attribute to a Pango Layout. Ouch. 

        -- Cyrille

-- 
Grumpf.