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

RE: ligature formation across text chunks

From: Rik Cabanier <cabanier@adobe.com>
Date: Thu, 26 May 2011 09:34:57 -0700
To: "'Glenn Adams'" <glenn@skynav.com>, Erik Dahlstrom <ed@opera.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: <8A13F0222395BD428969E5BA529EFA74778AA6E416@NAMBX01.corp.adobe.com>
Hi Erik,

I agree with Glenn on this.
In most cases, SVG will be produced by authoring tools and it is expected that it will behave like PDF in that the typography will look identical to the original layout.
If the selected font is not available, it is not unreasonable to things looks slightly different. The same will happen in Acrobat.

Rik

From: Glenn Adams [mailto:glenn@skynav.com]
Sent: Thursday, May 26, 2011 6:17 AM
To: Erik Dahlstrom
Cc: Rik Cabanier; Cameron McCormack; Tavmjong Bah; Vincent Hardy; public-svg-wg@w3.org
Subject: Re: ligature formation across text chunks

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<mailto: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<mailto: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<mailto: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<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<mailto: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<mailto: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<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<mailto: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<mailto: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<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<mailto: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<mailto: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> [mailto:public-svg-wg-<mailto:public-svg-wg->

> request@w3.org<mailto: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<mailto: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 16:35:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 May 2011 16:35:42 GMT