W3C home > Mailing lists > Public > public-svg-wg@w3.org > April to June 2011

Re: ligature formation across text chunks

From: Erik Dahlstrom <ed@opera.com>
Date: Thu, 26 May 2011 10:56:25 +0200
To: "Rik Cabanier" <cabanier@adobe.com>, "Glenn Adams" <glenn@skynav.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: <op.vv2y4bn8geuyw5@localhost.localdomain>
I don't think it's been mentioned in this thread, but absolute-positioning  
of glyphs will not really work well unless the font face used by the  
viewer is the same (or at least have very similar metrics) as the author  
intended. This is not guaranteed AFAIK, and I've seen a few such examples  
where the author didn't specify a font-family (or a font-family that is  
platform-specific) and you end up with large gaps between glyphs (or  
misalignments if you will) - that's an authoring mistake IMHO, but still  
it makes the content dependent on a particular viewer/default-font-face.  
That is a problem regardless of whether ligatures are formed or not, but  
might be a bigger problem if the author expected certain ligatures and the  
font face used by the viewer is different and doesn't have the expected  
ligatures defined. With webfonts at hand this problem is probably less of  
an issue, but even then there is no 100% guarantee that the viewer uses  
that face due to memory constraints, cross-site referencing, licensing,  
font-verification etc.

In general I think it's more common to not want absolute-positioned  
glyphs, but to use the x/y attributes as start/mid/end-points for text  
alignment.
/Erik

On Mon, 23 May 2011 21:42:24 +0200, Glenn Adams <glenn@skynav.com> wrote:

> The problem is that this will rule out 99.9% of all ligatures. It would  
> be
> rare indeed to have a ligature that takes up the same advancement as its
> component glyphs.
>
> On Mon, May 23, 2011 at 11:33 AM, Rik Cabanier <cabanier@adobe.com>  
> wrote:
>
>> •             As defined in CSS2, ([CSS2], section 16.4), when the
>> resultant space between two characters is not the same as the default  
>> space,
>> user agents should not use ligatures; thus, if there are non-default  
>> values
>> for properties ‘kerning’ or ‘letter-spacing’, the user agent should not  
>> use
>> ligatures.
>>
>>
>>
>> At first glance, this doesn’t seem to point to that direction. However,
>> this sentence is implying that the space between the characters in a
>> ligature is equal to the default space which isn’t the case very often.
>>
>>
>>
>> I think the rule should be:
>>
>> Ligatures can form if the space that the ligature takes up is equal to  
>> the
>> space of the individual glyphs (including the ‘kerning’ and  
>> ‘letter-spacing’
>> properties).
>>
>>
>>
>> With this rule, subsequent characters or text runs will stay in place  
>> and
>> if ligature substitution doesn’t happen, the output will still look  
>> somewhat
>> correct.
>>
>>
>>
>> Rik
>>
>>
>>
>> *From:* Glenn Adams [mailto:glenn@skynav.com]
>> *Sent:* Monday, May 23, 2011 10:14 AM
>>
>> *To:* Rik Cabanier
>> *Cc:* Cameron McCormack; Tavmjong Bah; Vincent Hardy;  
>> public-svg-wg@w3.org
>> *Subject:* Re: ligature formation across text chunks
>>
>>
>>
>> OK, i agree with your first point, but not with your second point; I  
>> would
>> not interpret the language about "resultant space between two  
>> characters" as
>> applying to the post-ligature results; I interpret this as "if the  
>> author
>> specifies kerning, letter-spacing, dx, x, etc., such that the default
>> spacing is changed" then ligation would be disabled; in the case
>>
>>
>>
>> <text x="100" dx="1 2 3">coffee</text>
>>
>>
>>
>> ligation of 'ff' would be permitted, since dx is zero for the second 'f'
>> and following;
>>
>>
>>
>> If it were:
>>
>>
>>
>> <text x="100" dx="1 2 3 1">coffee</text>
>>
>>
>>
>> then ligation would be disabled.
>>
>>
>>
>> Note that this creates a problem for an author that wants ligation to  
>> occur
>> *and* wants to specify an x or dx for the ligature glyph.
>>
>>
>>
>> G.
>>
>>
>>
>> On Mon, May 23, 2011 at 11:00 AM, Rik Cabanier <cabanier@adobe.com>  
>> wrote:
>>
>> Hi Glenn,
>>
>>
>>
>> In your example, there are additional offsets for ‘f’ so ligature  
>> formation
>> won’t happen.
>>
>> Reading the spec more closely, I came across this section:
>>
>> The following additional rules apply to ligature formation:
>>
>>    - As defined in  
>> CSS2<http://www.w3.org/TR/2008/REC-CSS2-20080411/text.html#spacing-props>,
>>    ([CSS2 <http://www.w3.org/TR/SVG/refs.html#ref-CSS2>], section 16.4),
>>    when the resultant space between two characters is not the same as  
>> the
>>    default space, user agents should not use ligatures; thus, if there  
>> are
>>    non-default values for properties  
>> *‘kerning’*<http://www.w3.org/TR/SVG/text.html#KerningProperty>
>>     or  
>> *‘letter-spacing’*<http://www.w3.org/TR/SVG/text.html#LetterSpacingProperty>,
>>    the user agent should not use ligatures.
>>
>> I **think** this means that ligatures will only form if
>>
>> -          There is no dx/dy offset in the <text> tag for the glyphs
>>
>> -          The spacing between the characters in the ligature is the  
>> same
>> as the 2 individual glyphs drawn with default positioning
>>
>>
>>
>> Rik
>>
>>
>>
>>
>>
>> *From:* Glenn Adams [mailto:glenn@skynav.com]
>> *Sent:* Monday, May 23, 2011 12:31 AM
>>
>>
>> *To:* Rik Cabanier
>> *Cc:* Cameron McCormack; Tavmjong Bah; Vincent Hardy;  
>> public-svg-wg@w3.org
>> *Subject:* 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/

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Thursday, 26 May 2011 08:57:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 May 2011 08:57:23 GMT