Last modified: 2013-08-28 21:45:34 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 4030 - EasyTimeline reversed text in RTL languages
EasyTimeline reversed text in RTL languages
Status: NEW
Product: MediaWiki extensions
Classification: Unclassified
EasyTimeline (Other open bugs)
unspecified
All All
: Normal major with 3 votes (vote)
: ---
Assigned To: Amir E. Aharoni
: i18n
Depends on:
Blocks: rtl 30790 53502
  Show dependency treegraph
 
Reported: 2005-11-19 13:48 UTC by Eran Roz
Modified: 2013-08-28 21:45 UTC (History)
11 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Eran Roz 2005-11-19 13:48:48 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 לנין)
Comment 1 Erik Zachte 2006-05-15 22:54:01 UTC
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. 

Comment 2 Pablo Saratxaga 2006-05-28 21:55:44 UTC
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)
Comment 3 Siebrand Mazeland 2008-08-13 11:49:23 UTC
Assigned to extension developer.
Comment 4 Amir E. Aharoni 2011-05-14 17:11:25 UTC
Just poking... This should be corrected.
Comment 5 Siebrand Mazeland 2011-08-02 12:43:27 UTC
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!
Comment 6 Amir E. Aharoni 2011-08-04 21:19:31 UTC
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.
Comment 7 Siebrand Mazeland 2011-09-08 07:59:08 UTC
Bug 30767 contained a patch to perltidy EasyTimeline.pl. Amir is close to submitting the first functional patch.
Comment 8 reza1615 2012-09-13 20:15:52 UTC
amir did you submit your patch?
Comment 9 Amir E. Aharoni 2012-09-14 03:58:28 UTC
I did, but it still has upstream problems. I'll try to fix it again.
Comment 10 Andre Klapper 2013-01-09 13:07:33 UTC
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]
Comment 11 kipod 2013-06-17 20:21:03 UTC
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.
Comment 12 Bawolff (Brian Wolff) 2013-06-18 00:26:32 UTC
(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...
Comment 13 kipod 2013-06-18 18:57:05 UTC
(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.
Comment 14 Amir E. Aharoni 2013-06-18 22:31:12 UTC
(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.
Comment 15 reza1615 2013-06-19 16:52:01 UTC
It's using obsolete "xfont"s.  It's beyond repair.  Easier to replace this
with another library than fixing it specialy for arabic fonts
Comment 16 Adam Wight 2013-08-09 09:30:49 UTC
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.
Comment 17 Bawolff (Brian Wolff) 2013-08-09 18:10:02 UTC
(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>
Comment 18 reza1615 2013-08-09 19:46:17 UTC
oooo finally it is solved :)
http://test.wikipedia.org/wiki/User:Yamaha5/time
Bawolff (Brian Wolff) and Adam Wight thanks
Comment 19 reza1615 2013-08-09 19:49:39 UTC
the farsi texts are OK but the links doesn't work :) and it is only an image
Comment 20 Adam Wight 2013-08-10 04:58:08 UTC
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).
Comment 21 Bawolff (Brian Wolff) 2013-08-28 17:47:33 UTC
(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.
Comment 22 reza1615 2013-08-28 18:00:00 UTC
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)
Comment 23 Bawolff (Brian Wolff) 2013-08-28 21:45:34 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links