This is definitely a bug (actually several) and it also demonstrates the problem I referred to earlier with Inkscape not reducing text to single direction blocks. What is happening here is that Compute Output is called with Block Progression set to R->L, however the Compute Output method involves in part a value which is the sum of the glyph widths added to the starting position. This is used to detect manual kerning in the string. Unfortunately that method is implicitly a L->R operation, so the code ends up thinking that every single R->L character is kerned and breaks them out into single character strings. When it hits the English word (L->R) that part of the code starts working properly.
Since Inkscape has not simplified the text into single direction spans in order to work properly it ends up requiring another part of the code to understand unicode bidirectional text. (Which here, it does not.) Even if the compute output section properly changed the + widths to - widths it would still have broken when it hit the English word, and would have reduced that string to single character strings instead. The processing the logic associated with bidirectional unicode should take place in a single location in the program, and that place is well before the generic print driver.
Regards,
David Mathog mathog@...1176... Manager, Sequence Analysis Facility, Biology Division, Caltech