- From: Glenn Adams <glenn@skynav.com>
- Date: Mon, 23 May 2011 01:30:56 -0600
- To: Rik Cabanier <cabanier@adobe.com>
- Cc: Cameron McCormack <cam@mcc.id.au>, Tavmjong Bah <tavmjong@free.fr>, Vincent Hardy <vhardy@adobe.com>, "public-svg-wg@w3.org" <public-svg-wg@w3.org>
- Message-ID: <BANLkTikxN2emsQ8PV_eq6K6D13P7=Cc=oQ@mail.gmail.com>
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/ > > >
Received on Monday, 23 May 2011 07:31:46 UTC