You can clone with
If the string for a label contains any numbers besides right-to-left text (arabic, farsi, hebrew...) the whole string gets rendered on a character by character basis.
So instead of "نامجو 17" you will get "ن ا م ج و 17". See this example in Mapnik openstreetmap: http://www.openstreetmap.org/?lat=36.27183&lon=59.57726&zoom=17
The weird thing is that the right-to-left text direction stays intact for the letters, but they are not concatenated correctly within the charset.
[grille_chompa] The detection of writing direction for strings seems to break once a number occurs in the string.
If you look at http://osm.org/go/zY1pNe@v0-- where the square label "میدان 17 شهریور" has a number in middle, you see that pre-number (looking from right to left) word alphabets are separated but the post-number word is OK.
Mapnik current doesn't perform the unicode bidirectional algorithm correctly. So it can't handle labels with both right-to-left and left-to-right character correctly. I'm rewriting the relevant part of mapnik and this problem should be gone in a few months.
/cc @grillechompa so he sees @herm's comment on the plan for this issue.
Thanks for the heads up, Dane.
FYI: The problem does not occur any more on the OpenStreetMap.org mapnik rendering any more. Not sure if it has been fixed by any preprocessing from OSM or via OSM. The examples mentioned before all render okay now.
Update itemizer to allow operation on text ranges (for line breaking).
Fix handling of reordered text runs (refs #519).
Closing this ticket as the issue is solved in the harfbuzz branch. Refs #1428.