Last modified: 2013-08-28 21:45:34 UTC
in RTL languages texts in timelines reversed. for example when writing in the code of the timeline: <timeline> ImageSize = width:160 height:450 PlotArea = width:50 height:430 left:50 bottom:10 DateFormat = yyyy Period = from:1919 till:1922 TimeAxis = orientation:vertical ScaleMajor = unit:year increment:5 start:1920 # there is no automatic collision detection, # so shift texts up or down manually to avoid overlap Define $dx = 25 # shift text to right side of bar PlotData= bar:Leaders color:red width:25 mark:(line,white) align:left fontsize:S from:start till:1922 shift:($dx,15) text:לנין </timeline> the result in the timeline will be ןינל (instead of לנין)
Yes, this is a known problem. It better be solved in rendering package Ploticus, which EasyTimeline uses for image rendering. Ploticus' author was contacted. He suggested someone familiar with RTL languages adds support to Freetype libraries, which Ploticus uses for text rendering. A workaround that simply reverses a text marked as RTL (with a new syntax element) would also have to take into account multi segments texts (for embedded links, where different colours are used). This makes it at least non trivial.
Pango (http://www.pango.org/) is a free software text rendering engine that works on top of freetype, it is good, and used by Gtk toolkit (Gnome, Gimp, etc.) So, maybe Ploticus author should look at it for the text rendering, instead of using freetype directly. (that would also solve context variants and ligaturing for arabic, indic scripts etc; that I suppose also render incorrectly as of now)
Assigned to extension developer.
Just poking... This should be corrected.
Resetting assignee. Unfortunately almost 6 years after being reported for the first time, we can still not make proper timelines in RTL wikis. Perl wizard needed!
I spoke to Erik at Wikimania today and he said that he'll be happy if i'd try to play with it. Assigning to myself.
Bug 30767 contained a patch to perltidy EasyTimeline.pl. Amir is close to submitting the first functional patch.
amir did you submit your patch?
I did, but it still has upstream problems. I'll try to fix it again.
Amir: This report has been in ASSIGNED status for more than one year and you are set as its assignee. In case that you are not actively working on a fix, please reset the bug status to NEW/UNCONFIRMED. In case you do not plan to work on a fix in the near future: Please also edit the "Assigned To" field by clicking "Reset Assignee to default", in order to not prevent potential contributors from working on a fix. Thanks for your help! [assigned>=1y]
this issue is somewhat frustrating, and also highlight a different issue: in scribunto extension, the "mw.ustring" module, that supposedly provides all of lua "string" functionality for unicode strings, omitted provide the "reverse()" function which could be used to mitigate this bug. fwiw, i created a "reverse" in [[he:Module:Strings]]. note that in order to use a template inside the parameters of timeline, you will need to use the magicward #tag:. using <timeline> directly will not expand templates, and hence will not reverse strings, even with one uses {{#invoke:Strings|reverse|מרמלדה}}. once you use {{#tag:timeline instead, this utility can be used. of course, it would be better if the extension took care of it, as i think it should. the solution should be laughably easy: do not even try to make an intelligent decision when a specific string needs reversing - just provide a new set of tokens, e.g., in addition to "text", give us "rtext" which will be reversed. we will still have to deal with stuff manually when including mixed-direction text, such as a sentence with both hebrew/arabic words and latin-script word, but teachin the extension to process "rtext" (or "rlegend" or "r"-anything that accepts-text-to-be-displayed) peace.
(In reply to comment #11) > > the solution should be laughably easy: do not even try to make an intelligent > decision when a specific string needs reversing - just provide a new set of > tokens, e.g., in addition to "text", give us "rtext" which will be reversed. > we > will still have to deal with stuff manually when including mixed-direction > text, such as a sentence with both hebrew/arabic words and latin-script word, > but teachin the extension to process "rtext" (or "rlegend" or "r"-anything > that > accepts-text-to-be-displayed) > Patches welcome :) Other possibilities, there are probably open source Bidi libraries we could hook into as well...
(In reply to comment #12) > Patches welcome :) > > Other possibilities, there are probably open source Bidi libraries we could > hook into as well... regarding patch: is there any test-suit this thing has? i would not want to fiddle with the core of this thing without some unit-test available. my familiarity with timeline and plotikus (or is it ploticus?) is not such that i would feel comfi with manual testing i devise myself. as to bidi library: i'm afraid it's too late for that now. doing something intelligent will break numerous plots that people already prepared on hewiki, arwiki, and fawiki where they painfully reversed all the legends manually. i believe my "solution" of adding new attributes for "rtl text/legend" will not disturb any of the existing plots, which use the "old" attribute with reversed content. peace.
(In reply to comment #13) > regarding patch: is there any test-suit this thing has? i would not want to > fiddle with the core of this thing without some unit-test available. my > familiarity with timeline and plotikus (or is it ploticus?) is not such that > i > would feel comfi with manual testing i devise myself. No, very sadly there's no test suite. I asked about this, too, when I started poking it. I'll try to fix it again when I'm back from my travels. > as to bidi library: i'm afraid it's too late for that now. doing something > intelligent will break numerous plots that people already prepared on hewiki, > arwiki, and fawiki where they painfully reversed all the legends manually. That's why I made proper bidi handling optional. > i believe my "solution" of adding new attributes for "rtl text/legend" will > not > disturb any of the existing plots, which use the "old" attribute with > reversed > content. If you have time, I suggest trying to hack on the current patch: https://gerrit.wikimedia.org/r/#/c/47336/ When it works, that should solve everything for all languages without making special changes for rtl. Special changes for rtl won't help Arabic anyway, because it won't connect the letters.
It's using obsolete "xfont"s. It's beyond repair. Easier to replace this with another library than fixing it specialy for arabic fonts
Good news-- it seems that base libraries have been fixed, and the only remaining issue is with svg->png conversion. Opening the intermediate svg file in firefox, the characters appear RTL, and are correctly joined together. ... as far as I can tell.
(In reply to comment #16) > Good news-- it seems that base libraries have been fixed, and the only > remaining issue is with svg->png conversion. Opening the intermediate svg > file > in firefox, the characters appear RTL, and are correctly joined together. > > ... as far as I can tell. The issue is with the direct ploticus->png method. The ploticus->svg->png method never had this issue, but has other problems (Usually involving cropping of timeline). You can experiment with ploticus->svg->png method by doing <timeline method="svg2png">timeline code here</timeline>
oooo finally it is solved :) http://test.wikipedia.org/wiki/User:Yamaha5/time Bawolff (Brian Wolff) and Adam Wight thanks
the farsi texts are OK but the links doesn't work :) and it is only an image
Please review https://gerrit.wikimedia.org/r/#/c/47336/ This should fix issues with the svg->png workaround. We should create a new global config variable to force svg2png for all timelines on affected wikis. I can't say whether we should stop using Ploticus png generation everywhere--let's discuss that at (bug 52689).
(In reply to comment #20) > Please review https://gerrit.wikimedia.org/r/#/c/47336/ > > This should fix issues with the svg->png workaround. > > We should create a new global config variable to force svg2png for all > timelines on affected wikis. I can't say whether we should stop using > Ploticus > png generation everywhere--let's discuss that at (bug 52689). Note, this won't fix the clickable links issue.
as Bawolff said in http://fa.wikipedia.org/wiki/%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1:Yamaha5/timeline_bug for example the clickable link for ''memphis group'' will be found on the 2 cm right and 1 cm bottom (near the side bar)
Ok, splitting off image map having wrong coordinates in svg2png mode to bug 53502. Resetting status to new. The patch in comment 20 is certainly a step in the right direction, but doesn't entirely fix this bug.
