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

Re: text-intro in SVG 1.1 2nd Edition

From: Nikolas Zimmermann <zimmermann@physik.rwth-aachen.de>
Date: Mon, 14 Mar 2011 18:11:25 +0100
Message-id: <22B55863-85E1-4B1B-8E67-DE3D5BB0DD0A@physik.rwth-aachen.de>
Cc: www-svg@w3.org
To: Erik Dahlstrom <ed@opera.com>

Am 14.03.2011 um 13:07 schrieb Erik Dahlstrom:

> 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.
Hey Erik,

thanks for the reply. Great to hear that Opera is also working towards getting all of them fixed. I'm still sitting on a patch which will make all (except one, which I think is incorrect, will write a separate mail for that) pass.

>> 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.
That warning page may be helpful. Is there a list of these tests somewhere? I can help to sync them.

>> 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.
Ouch, my bad! I should have checked the draft, sorry for that.

>> 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.
Correct and I think we should leave it as-is in 1.1F2.

>> 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.
Great, that is exactly what I wanted to ask for :-)

> 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'.
Excellent, I'll assure WebKit behaves the same.

I'll drop a line, once I can point out to a nightly build which aligns the direction/unicode-bidi handling with 1.1F2, for the curious :-)

Received on Monday, 14 March 2011 17:11:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:24 UTC