aboutsummaryrefslogtreecommitdiffstats
path: root/src
diff options
context:
space:
mode:
authorEli Zaretskii2010-11-06 20:19:32 +0200
committerEli Zaretskii2010-11-06 20:19:32 +0200
commit7d7cd6cef89a477357ec49b32565fd6659e983fe (patch)
tree1d4e914ba0533e53dd523a9dd158e8b48154e034 /src
parent5d8f9169b67b2a880d8cf2cb7daa5eeeea5e60ec (diff)
downloademacs-7d7cd6cef89a477357ec49b32565fd6659e983fe.tar.gz
emacs-7d7cd6cef89a477357ec49b32565fd6659e983fe.zip
xdisp.c: Add commentary about character compositions in bidirectional text.
Diffstat (limited to 'src')
-rw-r--r--src/xdisp.c32
1 files changed, 31 insertions, 1 deletions
diff --git a/src/xdisp.c b/src/xdisp.c
index 0fb480980cb..b3da4654213 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -214,11 +214,41 @@ along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>. */
214 leftmost character with special glyphs, which will display as, 214 leftmost character with special glyphs, which will display as,
215 well, empty. On text terminals, these special glyphs are simply 215 well, empty. On text terminals, these special glyphs are simply
216 blank characters. On graphics terminals, there's a single stretch 216 blank characters. On graphics terminals, there's a single stretch
217 glyph with suitably computed width. Both the blanks and the 217 glyph of a suitably computed width. Both the blanks and the
218 stretch glyph are given the face of the background of the line. 218 stretch glyph are given the face of the background of the line.
219 This way, the terminal-specific back-end can still draw the glyphs 219 This way, the terminal-specific back-end can still draw the glyphs
220 left to right, even for R2L lines. 220 left to right, even for R2L lines.
221 221
222 Bidirectional display and character compositions
223
224 Some scripts cannot be displayed by drawing each character
225 individually, because adjacent characters change each other's shape
226 on display. For example, Arabic and Indic scripts belong to this
227 category.
228
229 Emacs display supports this by providing "character compositions",
230 most of which is implemented in composite.c. During the buffer
231 scan that delivers characters to PRODUCE_GLYPHS, if the next
232 character to be delivered is a composed character, the iteration
233 calls composition_reseat_it and next_element_from_composition. If
234 they succeed to compose the character with one or more of the
235 following characters, the whole sequence of characters that where
236 composed is recorded in the `struct composition_it' object that is
237 part of the buffer iterator. The composed sequence could produce
238 one or more font glyphs (called "grapheme clusters") on the screen.
239 Each of these grapheme clusters is then delivered to PRODUCE_GLYPHS
240 in the direction corresponding to the current bidi scan direction
241 (recorded in the scan_dir member of the `struct bidi_it' object
242 that is part of the buffer iterator). In particular, if the bidi
243 iterator currently scans the buffer backwards, the grapheme
244 clusters are delivered back to front. This reorders the grapheme
245 clusters as appropriate for the current bidi context. Note that
246 this means that the grapheme clusters are always stored in the
247 LGSTRING object (see composite.c) in the logical order.
248
249 Moving an iterator in bidirectional text
250 without producing glyphs
251
222 Note one important detail mentioned above: that the bidi reordering 252 Note one important detail mentioned above: that the bidi reordering
223 engine, driven by the iterator, produces characters in R2L rows 253 engine, driven by the iterator, produces characters in R2L rows
224 starting at the character that will be the rightmost on display. 254 starting at the character that will be the rightmost on display.