Re: [Nautilus-list] Nautilus Pango porting

[Havoc Pennington <hp redhat com>]

Hi,

Hmm, I didn't quite absorb the USE_EEL_TEXT change. It looks like you
are trying to replace PangoLayout use with EelSmoothTextLayout.

Looking at eel-smooth-text-layout.c, I would say this code is entirely
broken from an i18n standpoint. The line breaking for example is
totally wrong. rsvg_ft_render_string() is broken as well; it expects
locale encoding rather than Unicode, and chooses/positions glyphs
in a very naive way that just is not correct.

Therefore I would argue we need to use PangoLayout as the backend for
all text rendering and editing. pango/pangoft2.h contains the routines
needed to render to a pixbuf (via an FT_Bitmap). If using PangoLayout
isn't possible, we at least need to be using the Pango shaping, text
boundary, etc. functionality.

Reading the source to GtkEntry and GtkLabel would probably be a good
way to learn about how to use PangoLayout.

Another random i18n bug in nautilus-icon-canvas-item.c:
  pieces = g_strsplit (combined_text, "\n", 0);
This needs to be done with pango_find_paragraph_boundary(), newlines
aren't the only paragraph separator. Or just create a multi-paragraph
PangoLayout.

Anyway, all text has to go through Pango or it's going to be
broken. At most it might make sense to reimplement the equivalent of
pango-layout.c (though that's a ton of work to get right due to the
bidi, split cursors, etc.), but even if the layout stuff is
reimplemented, there is really no alternative to using Pango for glyph
selection, line breaking, and so forth. i.e. pango_itemize(),
pango_shape(), and so on MUST be used or you're going to need to
reimplement the language-specific modules (see pango/modules/*) in
order to get things right.

Havoc