Re: pango_layout_iter_get_char_extents()



Hi,

I'll jump in here since the PangoLayoutIter is mostly my fault...
 
> I'm trying to write a customized GtkLabel that put three dots
> at the end of the visible text if the text does not fit into 
> the labels allocation and I'm having some problems with Pango.

This is the kind of thing that's pretty hard in a Unicode world...

> Looking at the code I found that it is determined as (cluster_width
> / char_count). The values returned here are however very small
> (about 1/8 the character height).  This makes
> pango_layout_iter_get_char_extents() pretty much useless for me and
> I wonder what it could be used for.
> 
> It would help me a lot if you could explain the differences
> between run, cluster and character. I have some ideas but I'm
> mostly guessing. Also, perhaps you have a better idea how to
> implement a Label as described here efficiently.

IIRC a run is a sequence of chars with the same attributes, most
importantly the same right-to-left direction and language and on the
same line. It's close to the same as a PangoItem but considers
PangoLayout's visual reasons to chunk up text in addition to
pango_itemize()'s logical reasons to do so. pango-context.c:583 shows
where items will get broken apart. Anyhow, runs/items are processing
chunks that we can treat as a whole.

A cluster is a block of characters represented by a single font glyph.
So say I have two characters, "a" and "add an accent to the previous
char", those combine into the "a with accent" char. This is why char
width is cluster_width/chars_in_cluster, because you divide the font
glyph among the chars that motivated the glyph.

A character is a "gunichar" and really may or may not represent a
linguistic character as perceived by users. The "as perceived by
users" character is a grapheme, which is often but not always the same
as a cluster, and identified by getting a PangoLogAttrs
(pango-break.h).

I believe PangoLayoutIter mostly returns the correct numbers since
it's used for all the selection code in GTK - but it's quite possible
there are some weird bugs.

Havoc





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]