W3C home > Mailing lists > Public > www-svg@w3.org > March 2011

Re: text-intro in SVG 1.1 2nd Edition

From: Erik Dahlstrom <ed@opera.com>
Date: Mon, 14 Mar 2011 13:07:13 +0100
To: www-svg@w3.org
Message-ID: <op.vsb097gkgeuyw5@localhost>
On Wed, 09 Mar 2011 15:19:49 +0100, Nikolas Zimmermann  
<zimmermann@physik.rwth-aachen.de> wrote:

> Hey SVG crowd,
>
> I've spent the last days assuring WebKits bidi implementation works as  
> expected for SVG text according to the i18n tests originally designed  
> for SVG Tiny 1.2:
> http://www.w3.org/International/tests/svg/test-direction-unicode-bidi-0  
> & http://www.w3.org/International/tests/svg/test-direction-alignment-0

If you look at Opera 11.10 [2] you'll see that we changed to pass more of  
those tests, some of the more complex ones may still be incorrect. I think  
Firefox 4 also changed some of the bidi handling for svg, which should  
mean it passes more of these tests as well.

> Cameron wrote a mail in December stating that text-intro-05-t.svg /  
> text-intro-09-t.svg are broken on most viewers, aka. looks not equal to  
> the reference image.
> Erik said,  
> http://lists.w3.org/Archives/Public/public-svg-wg/2010OctDec/0202.html,  
> that the test is identical to the SVG 1.2 Tiny version.
> I've looked a bit closer and found lots of inconsistencies that I'd like  
> to see resolved once for all :-)
>
> [... lots of links to various versions of 1.1 and 1.2T testsuites...]

Well, it would be nice to be able to point to a canonical resource for the  
tests, the dated versions are frozen and many things have changed since. I  
don't know if it's possible, but maybe the dated links could be pointed at  
a warning page with links to the latest versions. For the 1.2T tests that  
were based on 1.1 tests, it would be nice to get those in sync with 1.1SE.

...
> SVG 1.2 Tiny says:  
> (http://www.w3.org/TR/SVGTiny12/text.html#DirectionProperty)
> This property specifies the base writing direction of text and the  
> direction of embeddings and overrides (see 'unicode-bidi') for the  
> Unicode bidirectional algorithm.
> For the 'direction' property to have any effect on an element that does  
> not by itself establish a new text chunk (such as the 'tspan' element in  
> SVG 1.2 Tiny),  the 'unicode-bidi' property's value must be embed or  
> bidi-override.
>
> SVG 1.1 Second Edition says:  
> (http://www.w3.org/TR/SVG11/text.html#RelationshipWithBiDirectionality)

This is the latest editors draft:

     http://dev.w3.org/SVG/profiles/1.1F2/publish/text.html#RelationshipWithBiDirectionality
     http://dev.w3.org/SVG/profiles/1.1F2/publish/text.html#DirectionProperty

Please verify that your assertions still hold using the above editor's  
draft.

> To summarize: SVG 1.2 Tiny and SVG 1.1 Second edition have a different  
> "direction" attribute handling. <text direction="rtl" ..> has no effect  
> in SVG 1.1 Second Edition, as unicode-bidi is set to normal, per default.
> SVG 1.2 Tiny explicitly allows elements that establish new text chunks  
> to specify a direction attribute, regardless of the unicode-bidi value.

There is also a slight difference in that there are a few more text  
content elements in 1.1 than in 1.2T (tref, textPath, altGlyph), and that  
tspan can be absolutely positioned in 1.1 but not in 1.2T.

> The aforementioned SVG 1.2 Tiny i18n tests rely on <text direction="rtl"  
> unicode-bidi="normal" to take effect, other tests like  
> text-intro-02-b.svg in SVG 1.1 Second Edition, verify that setting
> text direction to rtl is ignored, when unicode-bidi is set to normal.  
> What behaviour do we want to have for SVG 1.1 Second edition? Align with  
> Tiny?

We did indeed have an ACTION-2921 to backport the relevant wording  
regarding this from 1.2T to 1.1 Second Edition, see changes here[1]. As  
you can see that change was made after the LC draft was published, so  
it'll go in the next publication.

The direction property should always have an effect on 'text content block  
elements' (<text>, <textArea>), but for inline elements you need to  
specify unicode-bidi for it to have an effect. In Opera I've made it so  
that even though the first character of a text content block element is  
(strongly) RTL the element is still handled according to what the computed  
value of the 'direction' property is, noting that the initial value is  
'ltr'.

Cheers
/Erik

[1]  
http://dev.w3.org/cvsweb/SVG/profiles/1.1F2/master/text.html.diff?r1=1.31;r2=1.32;f=h
[2] http://my.opera.com/desktopteam/blog/

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed
Received on Monday, 14 March 2011 12:07:50 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:47 GMT