Here is a test file:
http://saf.bio.caltech.edu/pub/pickup/hebrew_decorations1.svg
It starts with two Hebrew sentences (R->L) and ends with the English word "overline" (L->R). It is all overlined (text-decoration.) So the text is supposed to look like this:
__________________ --3--><--2--<--1--
The first Hebrew sentence is longer and the second one has two words of three characters each. (No browser I tried rendered this correctly, hence the long verbal description.)
Anyway, when an attempt was made to print this to an EMF file this is what was observed:
1. Each Hebrew character was sent as its own string. 2. In "style" both "direction" and "block_progression" computed values were set to 0. 3. The one English word was sent as a string (not character by character). Again, the direction and block_progression were set to 0.
Naively for this sentence I expected to see two calls to PrintEmf::text(), the first with all of the Hebrew and text direction nonzero, and the second all English and direction zero. Only the second part of that was correct. Before I try to "fix" it - is the current character by character behavior for R->L text intentional? (Not having tried to fix it yet, it could well be that this is a side effect of some of my changes.)
On a related note elsewhere, for instance, when rendering text to the screen, Inkscape leaves mixed L->R,R->L tspans in one piece - and then does some very strange things when one tries to navigate with the arrow keys within them to edit the text. Would it perhaps not be better to break up all mixed direction tspans that hit TNG compute into 2 or more tspans, each of which is either all R->L or all L->R characters, and for good measure, has the direction="rtl" and "ltr" tags set to match? Doing it the current way all sorts of other pieces of Inkscape have to know about bidirectional text. Without the tags being set other code cannot in general determine the tspan direction quickly - put 20 leading and trailing spaces around the core text, and the direction is not determined until something other than a space is encountered. Reduce all such tspans to homogeneous pieces in the TNG compute code and the rest of inkscape only needs to know how to handle the extra direction information for each tspan - which is much simpler to deal with than bidirectional text.
Thanks,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech