On 08/22/2011 09:00 PM, Philippe Verdy wrote:
The font tables themselves contain only ASCII characters I presume.
No. The lookup tables contain sequences of numeric glyph ids (16 bit
integers in TrueType and OpenType). Which are also not the code point
values, and not the character names or glyph names.
And numeric glyph IDs are still ASCII aren't they? I was just noting
that the glyph tables themselves don't *use* the actual codepoints of
the characters getting ligated (while they *refer* to them).
Let's say that;
- the LAMED character is cmap'ped (by its code point value in an cmap
for Unicode, or by its code position in a cmap for another legacy
8-bit encoding) to the glyph id 1012,
- and the ALEF character is cmapped to the glyph id 1001 (the values
of glyph ids are not important, not even their relative order or
differences, they don't need to obey any standard),
- and the ALEF-LAMED ligature is in glyph id 1540 (the ALEF-LAMED
character of the UCS may also be cmapped separately, but this is not a
requirement)
Then the lookup to perform the ligature will contain : (1012, 1001) -> (1540).
No! See Behdad's post -- it is clearly said that the lookup will still
be in logical order (1001, 1012) -> (1540) and not in visual order as
you say. See? This is what I meant in the other mail by you suggesting
that the tables containing the characters in visual order and not in
logical order, to which you replied (without much real explanation I'm
afraid):
<quote>No ! I've not "imagined" that. You incorrectly reinterpret
imaginatively another incorrect imaginative reinterpretation, made by
someone else, of what I wrote, which did not even suggest that.</quote>
Glyph id's are presented and scanned in the lookup table, in sequences
preordered in visual order by the text layout/shaping engine.
Nope -- they are placed in the lookup table in *logical* order. IIUC the
entire sequence of glyphs is only reordered from RTL at the very end.
Peter or Behdad, can you corroborate this?
--
Shriramana Sharma
