311545 - (svg-bidi) Support the 'writing-mode', 'direction' and 'unicode-bidi' properties in SVG

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Shlomi Israely]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

when viewing svg graphics containing hebrew (and I guess other RTL languages)
text, the characters are displayed in the wrong order (from left to right) as
seen in the following URL : 
http://welcome.linux.org.il/welcome-to-linux-2004.svg
and
http://img100.imageshack.us/img100/9829/svgbidi8hv.png

however, the order of the chars should be as seen here:
http://img98.imageshack.us/img98/6716/good6wq.png

the problem is in the blue hebrew text. instead of seeing:
ברוכים הבאים ללינוקס
you see:
סקונילל םיאבא םיכורב

Reproducible: Always

Steps to Reproduce:
1. open an SVG file conataining RTL text
2. see the RTL text rendered as if it is an LTR text.
Actual Results:  
the image contains strings rendered left to right.

Expected Results:  
the strings should be rendered right to left instead.

using Firefox 1.5Beta2, downloaded from mozilla.org (not from my linux distro).

Comment 1

[Uri Bernstein]

FWIW, on OS X, I don't see any Hebrew at all on the linked SVG (due to font issues?)
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051006
Firefox/1.4.1 ID:2005100606

Comment 2

[Tsahi Asher]

if relevant, there is no problem with win32 beta1, other than it looks much
smaller (about half the height and width) than the 2nd linked image.

Comment 3

[Tsahi Asher]

Mozilla/5.0 (Windows; U; Windows NT 5.1; he; rv:1.8b4) Gecko/20050913 Firefox/1.4
for the above comment

Comment 4

[Tomer Cohen :tomer]

Attachment: updated testcase

I've changed the original testcase to make it more Hebrew-friendly. 

Things done: 
* changed the writing-mode to "rl" for right-to-left. Still, no luck.
* The font used changed from David CLM (culmus.sf.net - linux only) to more
known Arial (Microsoft; available at corefonts.sf.net).

While working on the file I've found that changing the font-family to serif or
sans-serif make the text disappear. Should I open separated bug about this
behavior?

Comment 5

[Uri Bernstein]

I'm confirming the bug because it's well-reported and has a testcase (even
though i can't personally reproduce it on OS X).

Comment 6

[Barak]

(In reply to comment #2)
There is no problem with win32 1.5 beta 2 either.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051004
Firefox/1.4.1

Comment 7

[Simon Montagu :smontagu]

Judging by the distribution of where people are seeing this and where they
aren't, it looks as if SVG is just sending the string directly to the platfrom
rendering layer without any kind of Bidi processing. On platforms with native
Bidi support the right-to-left text is displayed correctly; on platforms
without, it is displayed reversed.

Comment 8

[zug_treno]

*** Bug 324210 has been marked as a duplicate of this bug. ***

Comment 9

[jessbody]

With regard to Simon's comment about native BIDI support, it is interesting to note that viewing the file http://geocities.com/urdutext/dial1.xml on IE with Adobe's plugin produces RTL Urdu text but the characters are not joined as they should be.

Comment 10

[tor]

Would like to fix this for 1.9, but doubtful that we'll block for it.  Some notes on how this might be implemented are here:

  http://weblogs.mozillazine.org/roc/archives/2007/03/text_text_text.html

Comment 11

[Boris Zbarsky [:bzbarsky]]

I assume it's not "wanted-1.9" because we're not in a position to make sure we allocate resources for it?

Comment 12

[tor]

(In reply to comment #11)
> I assume it's not "wanted-1.9" because we're not in a position to make sure we
> allocate resources for it?

No, it wasn't "wanted-1.9" because I forget about that annotation.  I don't think that keyword has any relation to what resources are available.

Comment 13

[Dão Gottwald [:dao]]

I'm supposed to work on a Ctrl+Tab tab switching panel for Firefox 3. I'm currently using SVG, and this bug hit me. The current version can be found at http://en.design-noir.de/mozilla/ctrl-tab/.

Comment 14

[(no longer active)]

Mass-assigning the new rtl keyword to RTL-related (see bug 349193).

Comment 15

[Tomer Cohen :tomer]

Attachment: Graph screenshot (Google Docs)

Google Have started producing SVG graphs in its Office Suite. Sadly, that feature is broken for some languages due to this Firefox bug. http://spreadsheets.google.com

Comment 16

[Simon Montagu :smontagu]

See also comments in bug 402276

Comment 17

[Tomer Cohen :tomer]

(In reply to comment #16)
> See also comments in bug 402276
> 

Dupe?

Comment 18

[Simon Montagu :smontagu]

Dependent at most.

Comment 21

[(no longer active)]

I tried to see if I can come up with a fix for it, and looked around the SVG code, but I couldn't find out where the text is actually rendered.  I expected to find the relevant code in either nsSVGTextFrame or nsSVGTextContainerFrame, but I didn't (and maybe I was looking in the wrong place).

Would fixing this involve in using something like nsLayoutUtils::DrawString for painting the text, or is it more involved than that?

Comment 22

[Simon Montagu :smontagu]

Text in SVG is rendered in nsSVGGlyphFrame.

What will make this more involved is the possibility of sub-elements being split up by bidi reordering. See http://weblogs.mozillazine.org/roc/archives/2007/03/text_text_text.html and bug 402276 comment 4 and following for some discussion.

Comment 23

[(no longer active)]

Thanks for the pointers.

So, here is what needs to be done, I think (please correct me if I'm wrong):

* Derive a bidi processor class from nsBidiPresUtils::BidiProcessor to handle the bidi processing and generation of textruns.
* Replace the mTextRun member with an array of text runs and populate this array in nsSVGGlyphFrame::EnsureTextRun by calling the bidi processor's ProcessText function with nsBidiPresUtils::MODE_MEASURE.
* Store a data structure in the bidi processor which maps indexes in the SVG text to indexes in specific text runs, so that we always know that the n'th character in the SVG text corresponds to the i'th character in the j'th textrun.
* Anywhere in nsSVGGlyphFrame where mTextRun is being used to figure out a dimension, use the map to get the dimension from the appropriate text run(s).
* Anywhere in nsSVGGlyphFrame where mTextRun is being used to draw the text, use the map to draw the appropriate text run(s).

Am I on the right track?

Comment 24

[Robert O'Callahan (:roc) (email my personal email if necessary)]

It's more complicated than that because the bidi processing needs to be done for the entire collection of nsSVGGlyphFrames which have a common nsSVGTextFrame ancestor.

Comment 25

[(no longer active)]

(In reply to comment #24)
> It's more complicated than that because the bidi processing needs to be done
> for the entire collection of nsSVGGlyphFrames which have a common
> nsSVGTextFrame ancestor.

What causes a piece of text to be broken into several nsSVGGlyphFrames?  In other words, what constitutes the boundary for each nsSVGGlyphFrame?  I couldn't find the code responsible for constructing individual nsSVGGlyphFrames inside nsSVGTextFrame...

Comment 26

[Robert O'Callahan (:roc) (email my personal email if necessary)]

One nsSVGGlyphFrame is created for each text node.

The problem is stuff like this:

<text>Eng<tspan>lish HEB</tspan>REW</text>

After bidi reordering you get something that renders as

<text>Eng<tspan>lish </tspan>WER<tspan>BEH</tspan></text>

Comment 27

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Keep in mind that the <tspan> may have its own style. So you really need to gather up all the text, perform bidi processing, and then place and paint the text in the appropriate styles. We'd have to stop keeping "covered regions" for individual glyph and span frames, since there can now be more than one region for a single frame. It's a mess.

An alternative would be to stop creating SVG frames for the contents of a <text>, and give it an anonymous block child and then create regular inline and text frames for <text> descendants. Then we can reflow the block as normal (well, not very normal, we'd need to use a reflow strategy like we do for foreignObject frames), but instead of rendering it normally, we could paint the <text> by walking the block frame subtree and extracting glyph positions and styles. We can't render the block normally because sometimes SVG text is rendered along a path... hit-testing and the SVG text DOM APIs would have to be modified to match. This is a fairly large project.

Comment 28

[(no longer active)]

(In reply to comment #26)
> One nsSVGGlyphFrame is created for each text node.
> 
> The problem is stuff like this:
> 
> <text>Eng<tspan>lish HEB</tspan>REW</text>
> 
> After bidi reordering you get something that renders as
> 
> <text>Eng<tspan>lish </tspan>WER<tspan>BEH</tspan></text>

Are SVG tspan's supposed to work similar to HTML span's?  I guess not, because they can be positioned anywhere.  (And on a similar note, should Arabic joining work across tspan boundaries or not?)

So if I understand this correctly, currently one text run is created per each <text> element, and for painting the text, the individual characters are iterated over and each one is rendered with its own style (which may be inherited from a <tspan>).  Is that correct?

And I don't understand why after bidi processing your sample would look like the result you mentioned.

(In reply to comment #27)
> Keep in mind that the <tspan> may have its own style. So you really need to
> gather up all the text, perform bidi processing, and then place and paint the
> text in the appropriate styles. We'd have to stop keeping "covered regions" for
> individual glyph and span frames, since there can now be more than one region
> for a single frame. It's a mess.

I'm not sure about the covered regions, but the first part kind of makes sense (see my comments above though).  Does the SVG spec say anything about how bidi resolution is supposed to work?  Or are there any reference implementations available which can be trusted to have implemented bidi resolution in SVG correctly?

> An alternative would be to stop creating SVG frames for the contents of a
> <text>, and give it an anonymous block child and then create regular inline and
> text frames for <text> descendants. Then we can reflow the block as normal
> (well, not very normal, we'd need to use a reflow strategy like we do for
> foreignObject frames), but instead of rendering it normally, we could paint the
> <text> by walking the block frame subtree and extracting glyph positions and
> styles. We can't render the block normally because sometimes SVG text is
> rendered along a path... hit-testing and the SVG text DOM APIs would have to be
> modified to match. This is a fairly large project.

I don't understand most of this paragraph...  :-)

Comment 29

[(no longer active)]

Another suggestion (which may be stupid!):  Can CharacterIterator be changed in a way that iterates over the string with the visual order (performing bidi resolution on the fly), so that the characters would be painted in the correct order by the same code which is painting them now?

Comment 30

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #28)
> Are SVG tspan's supposed to work similar to HTML span's?  I guess not, because
> they can be positioned anywhere.

So can HTML spans actually, via position:relative...

> (And on a similar note, should Arabic
> joining work across tspan boundaries or not?)

Yes, if possible.

> So if I understand this correctly, currently one text run is created per each
> <text> element, and for painting the text, the individual characters are
> iterated over and each one is rendered with its own style (which may be
> inherited from a <tspan>).  Is that correct?

Currently one text run is created per DOM text node. Shaping does not work correctly across span boundaries in SVG at the moment (it does in regular text).

> And I don't understand why after bidi processing your sample would look like
> the result you mentioned.

I'll attach a testcase.

> (In reply to comment #27)
> > Keep in mind that the <tspan> may have its own style. So you really need to
> > gather up all the text, perform bidi processing, and then place and paint
> > the text in the appropriate styles. We'd have to stop keeping "covered
> > regions" for individual glyph and span frames, since there can now be more
> > than one region for a single frame. It's a mess.
> 
> I'm not sure about the covered regions, but the first part kind of makes sense
> (see my comments above though).  Does the SVG spec say anything about how bidi
> resolution is supposed to work?  Or are there any reference implementations
> available which can be trusted to have implemented bidi resolution in SVG
> correctly?

I think it's fairly simple: SVG text content should behave just like the corresponding HTML content, when SVG-specific features are not present.

> > An alternative would be to stop creating SVG frames for the contents of a
> > <text>, and give it an anonymous block child and then create regular inline
> > and text frames for <text> descendants. Then we can reflow the block as
> > normal (well, not very normal, we'd need to use a reflow strategy like we
> > do for foreignObject frames), but instead of rendering it normally, we
> > could paint the <text> by walking the block frame subtree and extracting
> > glyph positions and styles. We can't render the block normally because
> > sometimes SVG text is rendered along a path... hit-testing and the SVG text
> > DOM APIs would have to be modified to match. This is a fairly large project.
> 
> I don't understand most of this paragraph...  :-)

OK, let me try to simplify:
1) create frames for SVG <text> and its descendants as if it was the corresponding CSS-formatted HTML
2) use our regular HTML/CSS text engine to lay out the text
3) when painting an SVG <text>, don't paint the child (HTML-ish) frames normally. Instead, walk the frame subtree, extract the glyph positions and styles, and render the glyphs the SVG way.

That gives you a lot of features "for free": full CSS formatting, bidi resolution, textrun construction and management, including text shaping across span boundaries.

Comment 31

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: mixed-direction testcase

Comment 32

[(no longer active)]

(In reply to comment #30)
> (In reply to comment #28)
> > Are SVG tspan's supposed to work similar to HTML span's?  I guess not, because
> > they can be positioned anywhere.
> 
> So can HTML spans actually, via position:relative...

Yes, you're right.  In order to convince myself, I tried this:

data:text/html;charset=utf-8,<div>Eng<span style="position: relative; top: 20px;">lish פרק</span>ליטו</div>

Although I should confess that I have never seen anything like this on the web before.  :-)

And for more fun, Arabic joining works there as well!

data:text/html;charset=utf-8,<div>Eng<span style="position: relative; top: 20px;">lish فای</span>رفاکس</div>

> > (And on a similar note, should Arabic
> > joining work across tspan boundaries or not?)
> 
> Yes, if possible.

Actually, in the current implementation, Arabic joining works correctly (well, the letters are correctly shaped, but from left to right).

> > So if I understand this correctly, currently one text run is created per each
> > <text> element, and for painting the text, the individual characters are
> > iterated over and each one is rendered with its own style (which may be
> > inherited from a <tspan>).  Is that correct?
> 
> Currently one text run is created per DOM text node. Shaping does not work
> correctly across span boundaries in SVG at the moment (it does in regular
> text).

Is there a bug filed on that?  If not, I'll file one.

> > And I don't understand why after bidi processing your sample would look like
> > the result you mentioned.
> 
> I'll attach a testcase.

Yeah, I see now.  For the HTML case, do we actually create separate <b> elements (or frames)?  Where does this magic happen, inside nsBidiPresUtils::ProcessText?

> > (In reply to comment #27)
> > I'm not sure about the covered regions, but the first part kind of makes sense
> > (see my comments above though).  Does the SVG spec say anything about how bidi
> > resolution is supposed to work?  Or are there any reference implementations
> > available which can be trusted to have implemented bidi resolution in SVG
> > correctly?
> 
> I think it's fairly simple: SVG text content should behave just like the
> corresponding HTML content, when SVG-specific features are not present.

Right.

> OK, let me try to simplify:
> 1) create frames for SVG <text> and its descendants as if it was the
> corresponding CSS-formatted HTML
> 2) use our regular HTML/CSS text engine to lay out the text
> 3) when painting an SVG <text>, don't paint the child (HTML-ish) frames
> normally. Instead, walk the frame subtree, extract the glyph positions and
> styles, and render the glyphs the SVG way.
> 
> That gives you a lot of features "for free": full CSS formatting, bidi
> resolution, textrun construction and management, including text shaping across
> span boundaries.

Thanks for the explanation.  I'm currently busy on some private browsing stuff which needs to be done for 1.9.1, but I will revisit it post-1.9.1, and try to implement this solution.

Comment 33

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #32)
> (In reply to comment #30)
> > Currently one text run is created per DOM text node. Shaping does not work
> > correctly across span boundaries in SVG at the moment (it does in regular
> > text).
> 
> Is there a bug filed on that?  If not, I'll file one.

I don't know, but there's not much point in filing a new bug if we fix it here.

> > I'll attach a testcase.
> 
> Yeah, I see now.  For the HTML case, do we actually create separate <b>
> elements (or frames)?  Where does this magic happen, inside
> nsBidiPresUtils::ProcessText?

We create separate frames, in nsBidiPresUtils::Resolve.

> > OK, let me try to simplify:
> > 1) create frames for SVG <text> and its descendants as if it was the
> > corresponding CSS-formatted HTML
> > 2) use our regular HTML/CSS text engine to lay out the text
> > 3) when painting an SVG <text>, don't paint the child (HTML-ish) frames
> > normally. Instead, walk the frame subtree, extract the glyph positions and
> > styles, and render the glyphs the SVG way.
> > 
> > That gives you a lot of features "for free": full CSS formatting, bidi
> > resolution, textrun construction and management, including text shaping
> > across span boundaries.
> 
> Thanks for the explanation.  I'm currently busy on some private browsing stuff
> which needs to be done for 1.9.1, but I will revisit it post-1.9.1, and try to
> implement this solution.

Yeah, I've flipflopped back and forth about which way is better, and I currently think this is the best way. We will probably have to put in some SVG-specific paths to the core text code --- mainly disabling features that shouldn't work in SVG --- but hopefully not too much. This way is probably easier than doing more involved work.

Step 1 involves hacking on nsCSSFrameConstructor. You'll want to create an anonymous block child for the <text> element, much like we do for foreignObjects, then create inline frames and text frames for the descendants. The SVG <textPath> element will need special handling, it will need to be a direct child of the nsSVGTextFrame. Boris or I can help you with that.

Step 2 involves copying the way nsSVGOuterSVGFrame reflows nsSVGForeignObjectFrames.

Step 3 is basically a lot of changes to nsSVGTextFrame to reimplement all the functionality that's currently in nsSVGGlyphFrame and nsSVGTextContainerFrame. You'll need to understand the existing code there and we'll need to talk about how it can be reimplemented using the frame positions and glyph data that nsBlockFrame/nsInlineFrame/nsTextFrame store.

Comment 35

[Kashif Aqeel]

Attachment: A sample file containing some Urdu text

This file contains urdu text that should be rendered from right to left with character joining within a word. Currently, the text is rendered from left to right without character joining

Comment 36

[Kashif Aqeel]

Attachment: Correct and incorrect rendering of Urdu text

This image shows correct and incorrect rendering of Urdu text

Comment 38

[(no longer active)]

Updating to reality: I won't have the time to work on this for the foreseeable future!

Comment 41

[Nadav Kavalerchik]

Any progress on this issue?

I can still reproduce this issue on Firefox 3.6.12 , Linux. ( and Windows )
While Chrome 10.0.624 dev renders the text just fine.

Issue can be reproduce using this sample:
( Taken from the Moodle 2 codebase which uses YUI 3 javascript )

<svg version="1.1" height="40" width="26" id="yui_3_2_0_1_1296843600557316"><text font-size="10px" y="40" transform="rotate(270, 6.5, 33.5)" xml:lang="he" direction="rtl" fill="rgb(0, 0, 0)" id="yui_3_2_0_1_1296843600557319">הגדרות</text></svg>

The Hebrew text display backwards.

Comment 42

[Cameron McCormack (:heycam)]

That example works in recent 4.0 betas, due to bug 620446.

Comment 43

[Shlomi Israely]

The linked example (from my original report) works with Firefox 4.0 from Archlinux. also works fine on Firefox 4.0 on Android.
I also checked the Nadav's example.

I think the status can be changed to "Resolved" then.

Comment 44

[Nadav Kavalerchik]

I confirmed. Issue is solved for Firefox 4.0 (Kubuntu 11.4)

Comment 45

[Simon Montagu :smontagu]

Simple cases work because of bug 620446, but this bug should stay open for a complete fix.

Comment 46

[Cameron McCormack (:heycam)]

Bidirectional text in SVG with the new SVG text frames should work now.  I don't think the Inkscape rendering of the attached test is correct, though there were some changes to the SVG specification at some point in the last couple of years to make sure that the direction property is used to determine the direction of the entire <text> element.

If you find any other specific problems, please open new bugs.