Re: logical index to visual index (Pango 1.0.1)

[Owen Taylor <otaylor redhat com>]

<dleach qnx com> writes:

> 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.

The result of a layout operation on a PangoLayout is a set of positioned
glyphs. You could certainly write routines to render subportions of
a PangoLayout.
 
> [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.

I'm not really sure I quite understand the problem. Is the place
where the fixed size messages are a problem when you are passing
the string to the layout operation or when you are passing the
resulting glyphs to the renderer?

It's not, in general, possible to figure out what subportion of a string
will appear in some visible position without actually laying out
the string.

But once you've laid out the string, you can perform a "clip" operation
on the resulting glyphs.

Regards,
                                        Owen