Right-to-left text-on-path misaligned in rsvg and batik

[Birdsaregood]

Using the Inkscape 0.45+devel, built Jan 25 2007 (beta 2 or 3?) version on
Windows XP:

I tried to make an SVG with (rotated) Hebrew letters, like this:
http://en.wikipedia.org/wiki/Image:OULogo.png.

When I made the svg and saved it, and then uploaded to Wikipedia
(http://upload.wikimedia.org/wikipedia/en/0/06/Oulogo.svg), the Hebrew
letters didn't show up. (I viewed it in both Firefox 2 and Internet
Explorer 7.)

Then I tried opening the svg file in Firefox, and the letters showed up but
were all mis-aligned. So I added Russian, Arabic, English, and Hebrew
letters. (Russian and English are left-to-right, Hebrew and Arabic are
right-to-left.) It didn't really matter if I rotated them or not, but the
left-to-right letters showed up properly while the right-to-left letters
were mis-aligned (basically, they were too far to the right). (I do not
know if the Arabic would, like the Hebrew, not show up if I uploaded this
new file to Wikipedia.)

So: Make sure that letters which go right-to-left save properly in Inkscape
so that when uploaded to the internet or viewed in other apps, it will work
properly.

[Birdsaregood (birdsaregood)]

Originator: YES

http://en.wikipedia.org/wiki/Image:Oulogo.svg is the address you can see
the SVG in Wikipedia missing the Hebrew.
http://upload.wikimedia.org/wikipedia/en/0/06/Oulogo.svg is the address
(for SVG supporting browsers) to see the SVG with the mis-aligned letters.

Everything looks normal in Inkscape, but not online.

[Buliabyak-users (buliabyak-users)]

Originator: NO

confirmed misalignment in batik

[Bryce Harrington (bryce)]

Originator: NO

Is this actually an Inkscape problem, or is it a bug in Batik and/or
firefox?

[Bug Importer (bug-importer)]

Well, I guess it's in Inkscape's save, because on Wikipedia, the Hebrew
svg letters didn't show up at all. It's hard to believe that Firefox,
Batik, and Wikipedia have bugs for right-to-left letters. Are there other
programs you can test it out in?

[Buliabyak-users (buliabyak-users)]

Originator: NO

It's not "hard to believe" at all. The status of SVG compliance is poor in
general, and in marginal areas such as right-to-left, doubly so. However,
we usually accept Batik as an authoritative renderer, and it was only
because it displayed this bug too that I didn't close this bug.

[Bug Importer (bug-importer)]

It also shows up misaligned in GIMP. Since this is the case, if it were
made in gimp with proper alignment, I doubt that this problem would occur.
I think the problem is in Inkscape.

And the other issue: Wikipedia can't display the Hebrew in the SVG. If you
would include a save feature which lets you save the image as an svg image
without actually recording the letters as letters or shapes as individual
elements, that would help. If you could save as a png, that might also help
(and would be a nice feature!).

[Buliabyak-users (buliabyak-users)]

Originator: NO

It's up to you. Convert text to path or export it all as PNG if you know
that your target software has weak or no SVG support.

[Bug Importer (bug-importer)]

I just found the option to save as PNG. Is this new to .45? It really
should show up along with the other save formats, though.

I have not found any way to convert text to path. How does one do this?

[Bug Importer (bug-importer)]

By the way, Wikipedia says they are fully svg compatible. -?-

[Buliabyak-users (buliabyak-users)]

Originator: NO

Export to png was a basic feature of Sodipodi/Inkscape since version 0.10
I think :)

Converting to path is, naturally, the first command in the Path menu :)

Claiming full support for SVG and being free of bugs, especially in
marginal and rarely tested areas, are two very big differences.

[Richard Hughes (cyreve)]

Originator: NO

I see what's going on here. Inkscape looks at the text, and passes it to
Pango to see what it makes of it. Pango replies that it's RTL, so Inkscape
sets the entire paragraph to be RTL and starts rendering leftwards. Batik,
Opera, Firefox, etc do not do this. They appear to be assuming that all
text is LTR (and hence rendering to the right of the starting point) unless
told otherwise, however I can't figure out how to tell them otherwise.
direction:rtl doesn't work, nor does writing-mode:rl-tb.

There is actually a comment in the code where I made this assumption,
saying that I don't know whether it's right and I need to talk to an RTL
speaker to find out. The w3c specs are not at all helpful. I'd appreciate
any advice anyone has on this, particularly the original poster who will be
able to compare Inkscape with how word processing apps behave.

SVG:
http://www.w3.org/TR/SVG11/text.html#RelationshipWithBiDirectionality
CSS: http://www.w3.org/TR/REC-CSS2/visuren.html#direction

[Birdsaregood (birdsaregood)]

Originator: YES

I converted the text to path, and it worked wonderfully. Thank you! (You
can still see the old version of the file here:
http://upload.wikimedia.org/wikipedia/en/archive/0/06/20070206230145%21Oulogo.svg)

In Microsoft Word, I can type in Hebrew and English in-line, just as with
Inkscape. I can type English, change the computer to Hebrew, continue
typing (this time RTL) to the right of the English, switch back to Hebrew,
and continue to type to the right of the Hebrew. If I export the Word
document as a .txt file, the Hebrew letters are replaced with question
marks, but are in the original position.

I don't know how to make Firefox know how to position it correctly. Maybe
there is an SVG standard for RTL? Is it possible to mark the positions RTL
letters were made in? Is it possible to convert all RTL letters into path
during a save, (with the potential for Inkscape to later recognize it was
once a letter and allow future text editing)?

Did I answer your question?

[Richard Hughes (cyreve)]

Originator: NO

In all my rambling, I didn't quite manage to actually ask a question. It
was supposed to be: should the overall directionality of a paragraph be
guessed based on the text in that paragraph, or must it always be
explicitly specified by the user? The overall directionality is what
controls stuff like which direction we go from the start point, and whether
'left' alignment aligns left or right.

[Buliabyak-users (buliabyak-users)]

Originator: NO

Here's what SVG 1.1 says:

The Unicode standard ([UNICODE], section 3.11) defines a complex algorithm
for determining the proper directionality of text. The algorithm consists
of an implicit part based on character properties, as well as explicit
controls for embeddings and overrides. The SVG user agent applies this
bidirectional algorithm when determining the layout of characters within a
'text' element. The 'direction' and 'unicode-bidi' properties allow authors
to override the inherent directionality of the content characters and thus
explicitly control how the elements and attributes of a document language
map to this algorithm. These two properties are applicable to all
characters whose glyphs are perpendicular to the
inline-progression-direction.

In most cases, the bidirectional algorithm from [UNICODE] produces the
desired result automatically, and overriding this algorithm properly is
usually quite complex. Therefore, in most cases, authors are discouraged
from assigning values to these properties.

I think this means we must honor the implicit directionality of
characters, which we (as I understand it) do. So looks like Inkscape's
behavior is more correct here.

[Birdsaregood (birdsaregood)]

Originator: YES

I think Word guesses based on the type of letters you use, but truth be
told, I would personally prefer to choose myself. This way, I can write in
Hebrew LTR if I want so other programs position the text properly, and if
there is a mix of text, it would be easier to select some text and choose
RTL and other text and choose LTR. RTL should by default be right align,
LTR should by default be left align. Does this answer your question?

[Bryce Harrington (bryce)]

Originator: NO

Marking as 'Works For Me' since it sounds like this is not an Inkscape
bug, but rather a RTL issue in Firefox and other applications.

birdsaregood, you should send bug reports to each program that claims SVG
support but doesn't handle RTL correctly; it would be good to point them to
this thread since there is interesting background in the discussion.

We can leave this bug Open, since there are some legitimate questions
remaining for discussion, but someone please close the bug when the
conversation has concluded or been moved to the mailing list.

[Richard Hughes (cyreve)]

Originator: NO

birdsaregood: Thanks, that's what I wanted to know. Inkscape does not
currently have any means of overriding the directionality of a paragraph,
however that's a feature request not a bug report. The workaround is to
explicitly specify a unicode LRM or RLM character at the beginning: ‎
or ‏

[Birdsaregood (birdsaregood)]

Originator: YES

Bryce, I thought Batik is the standard for SVG? Does this, too, have the
bug while only Inkscape is good? (Or should I say, too good?)

[Bryce Harrington (bryce)]

Originator: NO

Yes, generally we view Batik as the de facto standard, and use it as the
test case whenever we have questions about rendering.

However, it's not a universal standard, and it certainly is possible for
it to have bugs. The fact that Inkscape and Batik differ in their
behavior, and that Inkscape appears *more* correct is quite unusual, but
it's not outside the realm of possibility. This may be a situation of an
area of the spec that hasn't been widely tested, or it could be a
misreading of the spec.

It would be very helpful to talk with the Batik folks about their
interpretation of the SVG 1.1 spec, compared with what Bulia wrote.

[Birdsaregood (birdsaregood)]

Originator: YES

Okay.

**Note that the old image I linked to in my original question
(http://upload.wikimedia.org/wikipedia/en/0/06/Oulogo.svg) does not show
the problem image.** The correct link is
http://upload.wikimedia.org/wikipedia/en/archive/0/06/20070206230145%21Oulogo.svg
.

[Heycam (heycam)]

Originator: NO

[CCing the Batik bug
http://issues.apache.org/bugzilla/show_bug.cgi?id=41561]

As far as I know, the text layout is correct. Where the text is anchored
and which direction the text is rendered in are two different things.
Section 10.9 of SVG 1.1 says:

  The 'text-anchor' property is used to align (start-, middle- or
end-alignment)
  a string of text relative to a given point.

  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.

and for the "start" value (which is the initial value):

  The rendered characters are aligned such that the start of the text
string is
  at the initial current text position. For Latin or Arabic, which is
usually
  rendered horizontally, this is comparable to left alignment. For Asian
text
  with a vertical primary text direction, this is comparable to top
alignment.

So the anchoring of the text is independent of directionality. Test
text-intro-05 in the recently released SVG 1.1 test suite uses
text-anchor="end" on the text elements to right align the Arabic text.

Do you agree with this assessment?

[Heycam (heycam)]

Originator: NO

(and by "the text layout is correct" I mean the layout in Batik)

[Birdsaregood (birdsaregood)]

Originator: YES

RTL text should be right aligned. I can't really help you with the
technical stuff.

Here's another SVG example. But something is unusual. When viewed in
Inkscape, the text and the 3-D line look fine. In Firefox, a black box
takes place of the text area, and the line doesn't look the way it should.
In Gimp, the line looks okay, but the text is a black box there too. What's
going on?
File Added: test2.svg

[Heycam (heycam)]

Originator: NO

> Here's another SVG example. But something is unusual. When viewed in
> Inkscape, the text and the 3-D line look fine. In Firefox, a black box
> takes place of the text area, and the line doesn't look the way it
should.
> In Gimp, the line looks okay, but the text is a black box there too.
What's
> going on?

From Batik's perspective:

At some point, the SVG 1.2 Full draft changed such that the objects in the
flowRegion are actually required to be rendered. Thus you get the black
rects there. You should put a visibility="hidden" on those if you don't
want them rendered.

As for the missing text, the 1.2 Full draft used to require a flowDiv
element to be a parent of the flowParas. Batik wasn't updated after the
change to allow flowParas as children of the flowRoot. (We're holding back
on any more changes to the flow text support until another 1.2 Full draft
comes out.)

[Richard Hughes (cyreve)]

Originator: NO

heycam: Yes, that test in the test suite is fairly unambiguous. It's also
completely opposite to the text-align property in SVG12Mobile:
http://www.w3.org/TR/SVGMobile12/text.html#TextAlignProperty. I forsee an
annoying hack in my future...

[Bug Importer (bug-importer)]

> heycam: Yes, that test in the test suite is fairly unambiguous. It's
also
> completely opposite to the text-align property in SVG12Mobile:
> http://www.w3.org/TR/SVGMobile12/text.html#TextAlignProperty. I forsee
an
> annoying hack in my future...

Erk. I'll ask the WG.

[Chrislilley (chrislilley)]

Originator: NO

Is there a version that simply uses text on a path and a text string?

This should be doable with a single text on path, not all this
individual glyph positioning that either the author or inkscape
inserted.

[Heycam (heycam)]

Originator: NO

@cyreve:
Actually there is no compatibility problem between 1.1 and 1.2 Tiny.
text-align is used for the alignment of flowing text, while text-anchor is
the property that we were discussing. text-anchor is defined identically
in 1.1 and 1.2 Tiny, so you do need to add text-anchor="end" to the
individual text elements with each Hebrew letter in it.

But Chris' suggestion is best: a text path will handle all of this for
you.

[Richard Hughes (cyreve)]

Originator: NO

Yes, there is no problem with implementing this, it's just very odd.

[Richard Hughes (cyreve)]

Originator: NO

I've fixed this, which inevitably means I've broken your image. Sorry.

[Buliabyak-users (buliabyak-users)]

Originator: NO

thanks cyreve! since it's a bug that can affect rendering of old files,
can you please add a detailed note about it to
http://wiki.inkscape.org:8080/wiki/index.php/ReleaseNotes046: what files
are affected, how to fix their rendering, etc.

[Birdsaregood (birdsaregood)]

Originator: YES

Looks good! It shares the same alignment as other programs now, and it
seems to be just fine.