Re: text-anchor "middle" and "end" + dx

Hi Mike.

On 8/12/11 5:10 AM, Mike Bostock wrote:
> It appears that Firefox and Opera don't observe the dx attribute on
> text elements in conjunction with text-anchor "middle" or "end". For
> example, I would expect the dx attribute here to shift the text left
> by 10 pixels, and it does on WebKit, but not Firefox:
>
>    <text dx="-10" text-anchor="middle">Hello, world!</text>
>
> This bug was reported more than three years ago, and I haven't seen
> any progress on it:
>
>    https://bugzilla.mozilla.org/show_bug.cgi?id=454970
>
> Test case here:
>
>    http://zajec.net/bug/view/svg.text.anchor
>
> It's fairly easy to work-around this behavior by modifying the x
> attribute directly, but it's an annoying discrepancy between browsers.
> Which behavior is correct?

I think the spec is unclear in cases like this.  It says that for 
text-anchor="middle" the:

   rendered characters are aligned such that the geometric middle of the
   resulting rendered text is at the initial current text position.

Regarding the initial current text position, the spec says:

   The ‘text’ element renders its first glyph (after bidirectionality
   reordering) at the initial current text position, which is
   established by the ‘x’ and ‘y’ attributes on the ‘text’ element (with
   possible adjustments due to the value of the ‘text-anchor’ property,
   the presence of a ‘textPath’ element containing the first character,
   and/or an ‘x’, ‘y’, ‘dx’ or ‘dy’ attributes on a ‘tspan’, ‘tref’ or
   ‘altGlyph’ element which contains the first character).

but then later on it says:

   The ‘text-anchor’ property is applied to each individual text chunk
   within a given ‘text’ element. Each text chunk has an initial current
   text position, which represents the point in the user coordinate
   system resulting from (depending on context) application of the ‘x’
   and ‘y’ attributes on the ‘text’ element, any ‘x’ or ‘y’ attribute
   values on a ‘tspan’, ‘tref’ or ‘altGlyph’ element assigned explicitly
   to the first rendered character in a text chunk, or determination of
   the initial current text position for a ‘textPath’ element

Which makes it sound like the initial current text position can be 
affected by descendent x="" attributes like in <text x="10"><tspan 
x="20">abc</tspan></text>.  It still doesn't mention dx="", though, so I 
think that does not contribute to the determination of the anchor point.

In the definition of dx="" it says:

   The current text position is shifted along the x-axis of the current
   user coordinate system by <length> before the first character's
   glyphs are rendered.

So it is not really clear to me if, after the initial current text 
position is determined, dx="" is applied before or after the shift due 
to anchoring.


In my proposal to tighten up SVG's text layout 
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Text_layout I say

   d="" values are all applied after the initial layout of the text has
   been performed, but before any translation due to anchoring has been
   applied.

which is a little unclear.  What I mean is that we should resolve all of 
the x="" and dx="" attributes to get a list of absolute glyph positions, 
and then do anchoring after that, selecting the first value in the list 
of resolved absolute glyph positions as the anchor point.  It would make

   <text dx="100">abc</text>

which is equivalent to

   <text x="0" dx="100" text-anchor="start">abc</text>

render the left edge of the "a" at x = 100.

I still need to do a bit of work on the proposal to get everyone to 
agree upon it (which I should get back to at some point), so it's not 
the consensus of the group yet.

Received on Thursday, 8 December 2011 04:38:52 UTC