Re: logical index to visual index (Pango 1.0.1)

[<dleach qnx com>]

Owen Taylor <otaylor redhat com> said:

> 
> Derek Leach <dleach qnx com> writes:
> 
> > Hello Everyone,
> > 
> > Given the following string, in logical order:
> > 
> > <some hebrew> Hello
> > 
> > Imangine the visual order is as follows:
> > 
> > Hello <some hebrew>
> > 
> > Now, is there any way programmatically to determine,
> > given the logical index of the letter 'H',
> > the 'visual' index of the letter 'H', without
> > having to render the layout?  
[snip]
> 
> Pango doesn't really have an idea of the visual order of characters,
> it only deals with the visual order of "glyphs", so the idea of the
> visual index of a character isn't generally a useful concept.
[snip]

Sorry, I brought this across wrong.
I guess it would be better to say:

Is is possible to determine the 'glyph #'
in the sequence of rendering?

For example, 'H' is rendered first, 'e' second,
and so on.

[snip]
> It would be possible to get the idea of a visual position by just
> assuming that the characters within each glyph are ordered in the
> direction of the run.  (Pango already assumes something like this when
> there are multiple selectable entities within a cluster.) 
> 
> And it's certainly possible (if not terribly convenient) to compute this
> within the public Pango API.
> 
> But why do you want to do this? It's not an operation that I see much
> use for.

You will roll your eyes at this one.  The GUI that I am porting
this to, uses messages passing (to a resource manager), 
and a fixed size shmem buffer (only changes size 
on initial client connect).  So, it has to be possible to
perform multi-pass rendering when the resultant bitmap
does not entirely fit in the shmem buffer.  So, currently
this is working, because as the processing trucks along,
I have a running counter which is incremented after each
successful glyph write to the buffer.  When the buffer limit
is hit, the 'counter' is passed back and forth between
the resmgr and client, until the multi-pass has succeeded.

Now, with that little bit of background, let's take
it one bit further.  In visual order, our string
looks like "?hebrew".  Due to clipping, only the
last three "visual character cells" need to be displayed, "rew".
BUT, the client only has the logical string "hebrew?".
So, I was attempting to obtain the quickest method
for deriving the glyph positon of 'r'.

Boy, rereading that paragraph does not instill confidence
in my explanatory abilities.  If it does not make sense,
I will attempt to explain further.  Otherwise, I already
have a method for processing the layout (no bitmap rendering),
which I believe provides me with the information I require,
though at an expense of speed.

Thank You.