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

Re: ligature formation across text chunks

From: Glenn Adams <glenn@skynav.com>
Date: Thu, 26 May 2011 07:16:39 -0600
Message-ID: <BANLkTinNd3Za-aBEwcgFYHWYXDRQ8a6YsQ@mail.gmail.com>
To: Erik Dahlstrom <ed@opera.com>
Cc: Rik Cabanier <cabanier@adobe.com>, 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>
I agree "that it is more common to not want absolute positioned glyphs" but
only in the context of human produced SVG; for authoring tools, particularly
pre-press or typographic tools, the opposite is the case; i.e., absolute
positioned glyphs would be the norm.

Obviously if an author uses a logical font family or does not embed,
package, or have access to that font on the rendering side, they won't
necessarily get what they wish.

In the case of Apache FOP, native fonts are read directly by FOP in order to
make use of metrics and then recode and embed the font in the output format
of choice. It does use absolute positioning, both in x and y for individual
glyphs.

G.

On Thu, May 26, 2011 at 2:56 AM, Erik Dahlstrom <ed@opera.com> wrote:

> 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 13:17:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 May 2011 13:17:29 GMT