Page MenuHomePhabricator

EasyTimeline reversed text in RTL languages
Open, MediumPublicBUG REPORT

Description

Author: eran_roz

Description:
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

  1. there is no automatic collision detection,
  2. 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 לנין)


Version: unspecified
Severity: major

Details

Reference
bz4030

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 8:59 PM
bzimport added projects: EasyTimeline, I18n.
bzimport set Reference to bz4030.

erikzachte wrote:

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.

pablo wrote:

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.

@Amire80 , this is one of the oldest tasks assigned to someone. I wonder what is its status.

fwiw T55502 continues to be open.

Aklapper subscribed.
In T6030#968654, @Qgil wrote:

@Amire80 , this is one of the oldest tasks assigned to someone. I wonder what is its status.

Amire80: I am resetting the assignee of this issue to default (removing you) because there has been no progress in the last months (see T6030#85871). Feel free to take it again when you are actually planning to fix this. Thanks.

Aklapper changed the subtype of this task from "Task" to "Bug Report".Feb 6 2022, 7:18 PM