Bidi Emacs: R2L paragraphs and the direction of glyph_row

* Bidi Emacs: R2L paragraphs and the direction of glyph_row
@ 2009-10-17  9:15 Eli Zaretskii
  2009-11-26 14:58 ` Gregg Reynolds
  0 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2009-10-17  9:15 UTC (permalink / raw)
  To: emacs-devel; +Cc: emacs-bidi

This issue is borderline between design and implementation, but the
decision will affect lots of code to be written/changed later, so I'm
posting this here, in case there are some considerations that I
missed.

Display of paragraphs whose base direction is right-to-left needs to
begin at the right margin of the window, and the empty space at the
end of the line, if any, should extend all the way to the left margin.

By contrast, the terminal-specific back-end (which Emacs uses to
display what's in the glyph matrices) always draws glyphs from left to
right.  When the back-end is told that the face should be extended to
the end of the line, it just draws the amount of pixels needed to get
to the margin; the glyph matrix does not tell it how many pixels to
draw.  (The text-mode back-end is different, see below.)

To resolve this contradiction, what I plan to do is to introduce a
direction flag into the glyph_row structure.  When this flag is
left-to-right, glyphs will start at the lowest address in the
glyph_row->glyphs[] array and will proceed towards the highest
addresses, and the x coordinate will grow in that direction as well,
as it does today.  But when this flag is right-to-left, glyphs will
start at the highest address in glyph_row->glyphs[], so that the first
glyph is in glyph_row->glyphs[TEXT_AREA]+glyph_row->used[TEXT_AREA]-1
and the last glyph is in glyph_row->glyphs[TEXT_AREA].  The x
coordinate still grows left to right in this case, as it would on the
screen.

IOW, in the the right-to-left case, the glyphs in the glyph_row are
"reversed".  The code which walks glyph rows will need to process such
reversed glyph rows back to front, to keep the rest of the logic
generally intact.

The advantage of this is in the correspondence between the glyph
matrix and what's on the glass.  I expect that to minimize changes in
other parts of the code which need to find buffer position that
corresponds to a screen position, or look for glyphs in the matrices
given their screen positions.  (The alternative -- to keep glyph rows
in their current left-to-right direction, and reverse them in the
terminal-specific back-end -- sounds less attractive, as it would
require more coding in both the back-ends and in the generic parts of
the display engine.)

This idea of "reversed" glyph rows is already implemented for a
text-mode terminal, and works quite well.  Reversing the glyphs in
this case is relatively straightforward, since face extension is
implemented by filling the rest of the line with blanks.  After such
filling, reversal is trivial.  But for graphics terminals, this is
more complicated, and since I'm not an expert on those back-ends, I
thought I'd ask here if someone sees any reasons why doing the same
would be hard or require many changes in the existing code, even if
that happens only in some very special situations, like displaying
embedded images.

Does someone see any reason why calculating glyph coordinates "in
reverse" or extending the face to the left margin would be hard or
impossible on graphics terminals?  Does anyone see problems with the
idea of using "reversed" glyph_row in the display engine?

TIA

^ permalink raw reply	[flat|nested] 6+ messages in thread