Re: pango_layout_iter_get_char_extents()
- From: Havoc Pennington <hp redhat com>
- To: Sven Neumann <sven gimp org>
- Cc: Owen Taylor <otaylor redhat com>, gtk-devel-list gnome org
- Subject: Re: pango_layout_iter_get_char_extents()
- Date: 20 Jul 2001 10:39:03 -0400
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]