Re: about P1 part of BIDI alogrithm

> From: Philippe Verdy <verdy_p_at_wanadoo.fr>
> Date: Thu, 13 Oct 2011 15:56:06 +0200
> Cc: duerst_at_it.aoyama.ac.jp, libo.imc_at_gmail.com, unicode_at_unicode.org
>
> > This would mean to run the reordering twice, since you don't know
> > where to wrap a line until you lay out all of its grapheme clusters,
> > and you cannot do the layout until you reorder the characters.  That's
> > because the dimensions of each character are generally different, and
> > so without knowing which character will be the 1st on the line, which
> > the second, etc. _in_the_visual_order_, you cannot compute their
> > summary width, and without that you cannot decide where to break the
> > line.
>
> You've certainly not understood something. Reordering (of glyph ids,
> but *not* of characters) needs to be applied only ***onc1e***, only as
> the final step where you have already determined all linebreaks. You
> don't need any reordering for determining where to wrap lines.

It is entirely possible that I misunderstand something. However, I
think it's more likely that we miscommunicate because we use
"reordering" to refer to different things.

I believe you are using "reordering" to refer to what's described in
section 3.4 of UAX#9, i.e. the last stage of the UBA. By contrast, I
used "reordering" to refer to the entire processing described by the
UBA, i.e. the process by which I determine what character is to be
displayed next in the visual order. Sorry if this caused confusion.

> You absolutely ***don't need*** to use the "visual order" to compute
> widths of glyphs (generated after mirroring and substitions), all you
> need to know is where runs of text is changing its resolved direction
> between RTL and LTR.

To know where runs of text change direction, one needs to perform all
the stages of the UBA, up to and including I2. That's the bulk of the
algorithm, whose outcome is the resolved level of each character.

> Then the fact that a run by itself is RTL or LTR plays absolutely no
> role in the computed widths.

Because you assume that the width accumulation is done in logical
order, right? That's so only true as long as the UBA is taken as an
outline of implementation, not as requirements. In the Emacs display
engine, width is accumulated in visual order, because the layout level
of the display engine does not see the logical order at all.
Received on Thu Oct 13 2011 - 09:43:51 CDT