Re: ISSUE-2332: Comment regarding Text layout [SVG 1.1 F2 Last Call]

Hi Tav & group,

Thanks for your investigation into this.

 There were some very in-depth discussions about text
chunking, etc. a number of years ago that might affect this.
I will need to look them up.

 But, given the complexities that have been brought
up by this issue I would recommend it be postponed to after
1.1F2. It will likely take too much time out of the preparation
of 1.1F2 and I formally request it be deferred to the post-
1.1F2 time-frame. Whether it's 1.1F3 or 2.0 I don't mind,
but I think I've raised something that will require the
group to consider over a longer period.


--Original Message--:
> Issue 2332, Comment regarding Text layout was discussed at
>last weeks telcon. I've investigate the issue a bit further and
>have written up a short report that follows.
>     Tav
>Summary of issue:
>    The main question is how should ligatures be treated in regards to
>    the 'x', 'y', 'dx', 'dy', and 'rotate' attributes. 10.5 gives rules
>    for how the attributes are applied while 10.7.1 states that
>    ligatures should not be used if explicit values for 'x' or 'y' are
>    given as these create different "text chunks". This negates the
>    need for the rules in 10.5 to apply to 'x' or 'y'. (10.7.1 also
>    state ligatures should not be used if the kerning attribute or
>    letter-spacing attribute is non-zero.)
>    NB The attributes are applied to characters.
>Current browser behavior (using system fonts):
>  See:
>  Firefox 4.0b2pre: Uses ligatures, does not support letter-spacing,
>                    broken for ligatures with x, y, dx, dy, rotate 
>  Chrome 5.0.375.86 beta, Opera 10.60, Batik 1.7: Don't use ligatures.
>  IE9, Safari: Haven't tested.
>  Inkscape: Uses ligatures, letter-spacing does not break ligatures (bug),
>            breaks ligatures with x, y, dx, dy, rotate attributes
>  Uses:
>    It appears to me that there are two different use cases for text
>    (this echos the SVG font issue): High quality typesetting and
>    artistic layout. Which of these two is the main goal can determine
>    the desired behavior with regards to ligature.
>    * High quality type setting:
>        In this case, ligatures are usually desirable. In addition it
>        may be desirable to finely control character positioning. This
>        view supports not changing section 10.5 which allows
>        ligatures and the characters that follow ligatures to be
>        placed precisely. It requires, though, that the specified font
>        is available. (Erik notes that in some cases ligatures have
>        Unicode code points that can be explicitly specified.)
>    * Artistic layout:
>        In this case, ligatures may not be desirable. Consider the
>        word "Office". If used in a signboard with large
>        inter-character spacing, you would expect it to be rendered
>        something like this:
>        O  f  f  i  c  e
>        If you used a ligature, it would be rendered something
>        like this:
>        O ffi       c  e
>        If the designer has specified 'x' or 'y' (or 'rotate') values,
>        then a ligature is probably not what they intended. Clearly
>        you would not want the layout to vary depending on whether or
>        not a font includes ligatures (e.g. if a fallback font is used
>        with ligatures, when the primary font does not).
>  Latin alphabet perspective:
>    In Latin alphabets, ligatures are mostly a style issue, used to
>    improve the look or readability of text. Their use is never(?)
>    required. (There may be exceptions such as the German ß or Dutch ij
>    but these have separate Unicode points which are likely to be
>    explicitly used.) CSS2 dictates ligatures should not be used if
>    the spacing between the two characters is not the default spacing
>    (e.g line-spacing != 0 or kerning != auto).
>  Non-Latin alphabet perspective:
>    An expert should be consulted to determine if ligature use is
>    mandatory in some cases. Recall that 10.7.1 blocks ligature usage
>    in some cases. Arabic and Hindi scripts may require ligatures,
>    but at the same time they probably don't allow characters to be
>    moved arbitrarily around.
>Suggested solution:
>  For the short term:
>    Choose the "Artistic layout" perspective. This seems the closest
>    to the spirit of SVG.
>    Change the third and fourth bullet points in 10.5 to:
>    * When multiple XML characters map to a single glyph (e.g., when a
>      ligature is used) - Suppose that the i-th and (i+1)-th XML
>      characters map to a single glyph. In this case, the i-th value
>      for the ‘x’, ‘y’, ‘dx’, ‘dy’ and ‘rotate’ attributes all apply
>      when rendering the glyph. The (i+1)-th values ‘dx’ and ‘dy’ are
>      applied to the subsequent XML character (i.e., the (i+2)-th
>      character), if one exists, by translating the current text
>      position by the given amounts before rendering the first glyph
>      associated with that character. Note that the (i+2)-th character
>      may have its own corresponding 'dx' and 'dy' values that must be
>      included. Further note that 10.7.1 may prevent ligature
>      formation.
>    * When there is a many-to-many mapping of characters to glyphs
>      (e.g., when three characters map to two glyphs, such as when the
>      first glyph expresses the first character and half of the second
>      character, and the second glyph expresses the other half of the
>      second character plus the third character) - Suppose that the
>      i-th, (i+1)-th and (i+2)-th XML characters map to two glyphs. In
>      this case, the i-th value for the ‘x’, ‘y’, ‘dx’ and ‘dy’ values
>      are applied (i.e., the current text position is adjusted) before
>      rendering the first glyph. The rotation transformation
>      corresponding to the i-th ‘rotate’ value is applied to both the
>      two glyphs and the glyph advance values for the first glyph on a
>      group basis (i.e., the rotation value creates a temporary new
>      rotated coordinate system, and the two glyphs are rendered into
>      the temporary rotated coordinate system). The (i+1)-th and
>      (i+2)-th values for the ‘dx’ and ‘dy’ attributes are applied to
>      the subsequent XML character (i.e., the (i+3)-th character), if
>      one exists, by translating the current text position by the
>      given amounts before rendering the first glyph associated with
>      that character.
>    Add a bullet point to 10.7.1:
>    * Ligature formation should not be used when the second or later
>      character that could form part of a ligature has a 'rotation'
>      value different from that of the first character.
>   (Comment: I would think that dx and dy should also break ligatures.)
>  For the long term (SVG2):
>    Add a use-ligature (always, never) attribute which
>    would determine between 10.5 and 10.7.1 behavior.
>    Erik points out that there is the text-rendering attribute
>    that might be useful.

Received on Wednesday, 7 July 2010 07:45:43 UTC