Re: ligature formation across text chunks

I believe that is the implication: "that the authoring application should be
aware that the SVG viewer is going to create a ligature and move the ‘e’
more to the left". Or at least that is my presumption in the absence of
specifying x or dx coords for each output glyph. That is, if you have:

(1) <text x="100">coffee</text>

renderer may substitute 'ff' ligature and would adjust the origin of the
following 'e' glyphs accordingly

(2) <text x="100" dx="0 0 1 2 -1 0">coffee</text>

renderer may substitute 'ff' ligature and would adjust the origin of the
following 'e' glyphs accordingly;
furthermore, the current definition of dx on text & tspan (in SVG1.1) says
that the entries in dx correspond to "the glyphs corresponding to the first
n characters within this element"; in the case that a ligature is
substituted we have a case where the 'ff' ligature is subject to two
apparent dx adjustments, '1' and '2' as associated with the two 'f'
characters; this is probably not the intended result but it remains an
ambiguity in the current definitions of multiple x/dx (y/dy) entries in case
there is not a 1:1 character to glyph mapping;

G.

On Sun, May 22, 2011 at 10:43 PM, Rik Cabanier <cabanier@adobe.com> wrote:

> Hi Glenn,
>
>
>
> I don’t quite understand what you’re saying.
>
> In my example ‘ff’ is an optional ligature, but the letter spacing is not
> the default as witnessed by the word being shorter with ligatures vs 2
> simple glyphs.
>
> So, if an author emits ‘coffee’ with all default letter spacing and SVG
> decides to substitute ‘ff’ for a ligature, there will be more space between
> ‘f’ and ‘e’ which will look incorrect.
>
> Are you suggesting that the authoring application should be aware that the
> SVG viewer is going to create a ligature and move the ‘e’ more to the left?
>
>
>
> I agree that there should be a mechanism to emit glyph id’s so you can pick
> the desired character from a font but that is a different problem.
>
>
>
> Rik
>
>
>
> *From:* Glenn Adams [mailto:glenn@skynav.com]
> *Sent:* Thursday, May 19, 2011 9:44 PM
> *To:* Rik Cabanier
> *Cc:* Cameron McCormack; Tavmjong Bah; Vincent Hardy; public-svg-wg@w3.org
>
> *Subject:* Re: ligature formation across text chunks
>
>
>
> The cited text indicates that if space between characters is not the
> default (i.e., letter spacing has been applied), then the UA should NOT use
> an optional ligature. Since 'ff' is an optional ligature, then letter
> spacing should block ligature formation in this case.
>
>
>
> However, if letter space does not apply, then, on the presumption that the
> UA is performing the character to glyph mapping process, it may choose to
> use the ligature.
>
>
>
> The question here may be whether there should be some mechanism by which
> the author can indicate that no character to glyph mapping process be
> applied, i.e., other than the nominal CMAP process which is necessary. That
> is, how can the author declare that no substitution (including ligatures)
> should occur even in the absence of letter spacing.
>
>
>
> G.
>
> On Thu, May 19, 2011 at 10:17 PM, Rik Cabanier <cabanier@adobe.com> wrote:
>
> > > > When the resulting space between two characters is not the same as
> > > > the default space, user agents should not use optional ligatures.
> >
> > I missed that, thanks.
>
> I do not believe that us true. For certain ligatures, the characters will
> be closer together than the individual glyphs.
> See the attached PDF as an example.
> This is also the reason that the auto-generation of ligatures in SVG is not
> a good idea because it will create gaps or overlap with subsequent glyghs.
>
> Rik
>
>
>
> > -----Original Message-----
> > From: public-svg-wg-request@w3.org [mailto:public-svg-wg-
>
> > request@w3.org] On Behalf Of Cameron McCormack
> > Sent: Thursday, May 19, 2011 9:03 PM
> > To: Glenn Adams
> > Cc: Tavmjong Bah; Vincent Hardy; public-svg-wg@w3.org
> > Subject: Re: ligature formation across text chunks
>
> >
> > Glenn Adams:
> > > The current css3-text has the following under [1]:
> > ...
> > > > If the UA cannot expand a cursive script without breaking the
> > > > cursive connections, it should not apply letter-spacing between
> > > > grapheme clusters of that script at all.
> > >
> > > > When the resulting space between two characters is not the same as
> > > > the default space, user agents should not use optional ligatures.
> >
> > I missed that, thanks.
> >
> > > This text provides for the Arabic Script case (a cursive script), by
> > > indicating that the space to be extended is between disjoint graphemes.
> > > Furthermore, this text provides for the case that only optional (but
> > > not
> > > mandatory) ligatures be disabled when a letter space would apply
> > > between the characters that contribute to the ligature's component
> > allographs.
> >
> > That sounds reasonable.
> >
> > > I believe this text (the last sentence) may be acceptable in Indic
> > > scripts as well, since it only prevents optional conjunct formation in
> > > the case that letter spacing is non-zero. The only issue then is if an
> > > author wanted to use letter spacing *and* still have (some or all)
> > > optional ligatures
> > > (conjuncts) used. The alternative in that case would be to use an
> > > authoring tool that performs its own letter spacing and outputs glyphs
> > > at specific origins.
> >
> > Maybe font-variant can be used to force optional ligatures to be used in
> this
> > case?
> >
> > --
> > Cameron McCormack ≝ http://mcc.id.au/
>
>
>