Re: ligature formation across text chunks

It may be useful to describe the output of my work on FOP just after the
line layout process, which is preceded by bidi processing  (in order to
assign a bidi level to each input character) and by character to glyph
substitution and positioning process, i.e., OpenType GSUB and GPOS
processing.

Here is an abstracted, semi-formal description of the output of this
process:

line-area  : ipd ( word-area (space-area word-area)* )?
word-area  : ipd glyph-area+
glyph-area : ipd font-id glyph-id pos-adj text-assoc
space-area : ipd text-assoc
ipd        : distance                    // inline progression dimension
bpd        : distance                    // block progression dimension
pos-adj    : org-dx org-dy adv-dx adv-dy // positioning adjustments
org-dx     : distance                    // origin-x adjustment
org-dy     : distance                    // origin-y adjustment
adv-dx     : distance                    // advance-x adjustment
adv-dy     : distance                    // advance-y adjustment
text-assoc : text-id text-range+         // back pointer to original text
text-range : start end                   // half-closed interval on original
text

A line is drawn as follows (for horizontal lines):

draw-area(line-area) {
  foreach ( area in line-area ) {
    draw-area(area)
    current-x += ipd(area)
  }
  current-y += bpd(line-area)
}

draw-area(word-area) {
  temp-x = current-x                 // use temporary current x within word
  temp-y = current-y                 // use temporary current y within word
  foreach ( glyph in word-area ) {
    a = pos-adj(glyph)               // get position adjustments
    x = temp-x + org-dx(a)           // apply x origin adjustment
    y = temp-y + org-dy(a)           // apply y origin adjustment
    draw-glyph ( font-id(glyph), glyph-id(glyph), x, y )
    temp-x += ipd(glyph) + adv-dx(a) // advance x with adjustment
    temp-y += adv-dy(a)              // advance y with adjustment
  }
  current-x += ipd(word-area)        // advance by word area's ipd
  current-y += 0                     // maintain baseline
}

Some comments on the above:

   - various drawing and important interactive properties are omitted, such
   as color, decorations, bidi level, etc.;
   - the four part per-glyph position adjust (pos-adj), allows making
   temporary adjustments of a glyph's origin, and permanent (within a word
   area) adjustments of its advanced position, both in x and y; all four
   adjustments are required by OpenType GPOS processing;
   - the reverse mapping to (association with) the originating text
   (text-assoc) supports N:M discontiguous mappings, which is an outcome of
   OpenType GSUB processing; e.g., the 3rd glyph in a word area may be derived
   from a complex substitution process that maps from the 1st through 2nd and
   5th through 7th characters, i.e., ranges { [0,2], [4,7] }, of the
   originating text;
   - the drawing process above is based on drawing from left to right (in a
   horizontal line context) independently from bidi considerations; that is,
   line and word areas have already been reordered so that drawing from left to
   right (increasing x) will produce the intended visual result;
   - glyph areas that refer to combining marks (i.e., have an inherent
   advancement of 0) will have already been reordered as well so that they are
   drawn prior to drawing the base glyph; if this were not the case, then the
   org-dx(adjust) and org-dy(adjust) values would have to take into account the
   final advanced position of the base glyph to which they attach;

My interface for output from FOP to SVG is going to be the draw-glyph()
interface above, though it is possible that I will collect a sequence of
drawn glyphs that employ a single font, in which case I will specify the
final x position of each glyph as you indicate in your example below.
However, I wonder how an SVG UA knows that I have already done the character
to glyph mapping process and that it should not treat this <text/> as
characters to undergo the same processing I have just completed?

My sense is that SVG should have two distinct elements, one for use in
drawing a sequence of glyphs, another for use in drawing a sequence of
characters (with implied mapping to glyphs). Using <text/> for both purposes
seems problematic.

Regards,
Glenn

On Tue, May 17, 2011 at 6:05 PM, Cameron McCormack <cam@mcc.id.au> wrote:

> Cameron McCormack:
> > Assuming we’re not using the implementation’s text shaping engine, you
> > would want to output (assuming we’re using SVG fonts):
> >
> >   <font>
> >     <glyph id="g1" d="..."/>
> >     <glyph id="g2" d="..."/>
> >     <glyph id="g3" d="..."/>
> >     <glyph id="g4" d="..."/>
> >   </font>
> >   <altGlyphDef id="a">
> >     <glyphRef xlink:href="g1"/>
> >     <glyphRef xlink:href="g2"/>
> >     <glyphRef xlink:href="g3"/>
> >     <glyphRef xlink:href="g4"/>
> >   </altGlyphDef>
> >   <text glyph-x="10 20 30 40"><altGlyph
> >     xlink:href="#a">zzzzzzzzzzzz</altGlyph></text>
> >
> > is that right?  The glyph-x="" gives the position of each glyph (or we
> > could keep using x="").  We still don’t have the mapping of character
> > indexes to glyph indexes, which would be necessary for text selection to
> > work properly.  The glyphs would be positioned correctly, though,
> > because we just ensure that the <glyphRef>s are in the order glyph-x
> > expects.
>
> And here is where I realise that x="" and the current lack of character-
> to-glyph map cannot work even for rendering.  If we have glyph-x="",
> then we don’t need the character-to-glyph-map for rendering, since we
> can rely on the order in the <altGlyphDef>.  If we have the character-
> to-glyph map then we could keep using x="" with its dummy values in
> between the four important values.
>
> --
> Cameron McCormack ≝ http://mcc.id.au/
>