Last modified: 2014-01-31 09:08:08 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 21497 - Allow using custom fonts with EasyTimeline
Allow using custom fonts with EasyTimeline
Product: MediaWiki extensions
Classification: Unclassified
EasyTimeline (Other open bugs)
All All
: Low major (vote)
: ---
Assigned To: Nobody - You can work on this!
: i18n, utf8
Depends on: 8898
Blocks: 41348 54213 56295
  Show dependency treegraph
Reported: 2009-11-13 02:51 UTC by praveenp
Modified: 2014-01-31 09:08 UTC (History)
17 users (show)

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

Problem Screenshot (142.15 KB, image/png)
2009-11-13 03:14 UTC, praveenp
Didn't work completely (135.53 KB, image/png)
2010-01-25 16:12 UTC, praveenp
No liguatures rendering (19.16 KB, image/jpeg)
2011-02-19 18:57 UTC, praveenp

Description praveenp 2009-11-13 02:51:51 UTC
Instead of creating Malayalam Characters EasyTimeLine renders squares.
Comment 1 praveenp 2009-11-13 03:14:31 UTC
Created attachment 6776 [details]
Problem Screenshot
Comment 2 Bawolff (Brian Wolff) 2010-01-14 00:17:06 UTC
This is definitely a font issue. I just tried using the timeline extension with a different font (FreeSerif. wikimedia uses FreeSans for this extension), and the Malayalam characters rendered fine (well what i assume to be fine. I can't read Malayalam, so it could be giberish for all i know, but it looked what i imagine Malayalam would look like).

Since we don't have a font that covers everything, and even if we did, I could imagine cases where people would want to specify a different font then the default for their timeline, perhaps the solution would be to have a font parameter for the timeline tag

<timeline font="someFont">timeline code...</timeline>

Currently the font to use is passed as a hard coded command line argument to ploticus in , So i'd imagine it wouldn't be too difficult to allow alternate fonts to be selected  by the user.
Comment 3 Niklas Laxström 2010-01-14 08:49:10 UTC
Users don't know what fonts are installed on the server. Font-config can be used to automatically select best font given a language code, so maybe we should allow tagging the language instead.
Comment 4 praveenp 2010-01-14 11:59:34 UTC
If lack of font is the only problem then I think I can arrange atleast one ;-)
Comment 5 Bawolff (Brian Wolff) 2010-01-14 12:16:01 UTC
The problem seems to be not so much a lack of fonts to choose from (the servers have a large number of fonts installed to render the svgs). It is the fact that the extension is hard coded to use FreeSans (from the GNU free font collection) , which unicode coverage does not include Malayalam.
Comment 6 Bawolff (Brian Wolff) 2010-01-24 22:47:03 UTC
Praveen P: btw, there is a (ugly) work arround you can do to get timelines with Malayalam characters.

EasyTimeline generates svg's for all its timelines (which it does not use whatsoever - their generation is probably a bug). If you find the url of the png (in the example given: ) change the extension to svg ( so ). Save the svg file, in a text editor replace encoding="iso-8859-1" on the first line with encoding="UTF-8" (the svg part of easytimeline passes wrong args to ploticus for xmlencoding).Then go through and replace any &amp;nbsp; with &nbsp; . Upload the resulting file, and you should have a timeline with the proper internationilized characters.
Comment 7 praveenp 2010-01-25 16:12:58 UTC
Created attachment 7015 [details]
Didn't work completely

Bawolff tip doesn't work completely for me. But it displyed Malayalam characters randomly. And main point is there may be much easier tools to create graph images locally ;-)
Comment 8 Junaid 2010-01-26 08:14:27 UTC
Adding an option to produce SVG instead of PNG and setting encoding to utf-8 should solve the problem. won't it?
Comment 9 Erik Zachte 2010-01-26 09:59:45 UTC
> EasyTimeline generates svg's for all its timelines 
> (which it does not use whatsoever - their generation is probably a bug). 

Well not really a bug. Rather a hidden feature. The svg's were used occasionaly for presentations.


In 2006 I made an updated EasyTimeline with better font support. It actually depended on a Ploticus hack that was made specifically for this purpose: Ploticus needed to return x,y positions for rendered texts so that hyperlinks (blue links texts positioned over black texts would be positioned correctly with proportional font). I tested it in cygwin and it worked. Hopefully that font metric enhancement is now part of normal Ploticus build. 

The new Easytimeline script got new ParseFonts proc. 

For several reasons I did not follow up ever since. I just uploaded the patched script to in case someone is interested.

As an aside, I am also looking for someone to adopt the whole project, as in reality my contribution has been zero for too long now.
Comment 10 Bawolff (Brian Wolff) 2010-02-05 07:18:17 UTC
btw, I made the font into a configuration setting in r62018 (Not quite the same as using fontconfig, but was a lot simpler, and certainly a step in the right direction). Next step would be to have wikimedia use a different font in languages not supported by FreeSans.

Also fixed the svg character encoding issue in r61705 .
Comment 11 Bawolff (Brian Wolff) 2011-02-04 19:39:57 UTC
As of r62018, easy time line supports specifying alternate fonts in LocalSettings.php. Changing to a shell request.

The relevant setting is something like:
$wgTimelineSettings->fontFile = "fontFile.ttf"

probably would also want to update:
$wgTimelineSettings->epochTimestamp = '20081209214953';
to something more recent (Currently specified as above in CommonSettins.php)

fontFile.ttf must be in the path specified by $GDFONTPATH environment variable. (Which i believe for wikimedia is /usr/local/apache/common/fonts .)

As for which fontFile, presumably we already have at least one malayalam font installed for the svg renders(?), but probably not in the right directory needed for easyTimeline.

See also bug 20825

It might also be interesting idea to change the default font for all wikis to be DejaVu Sans, since that supports significantly more characters than FreeSans (the current default) afaik, however that might break pre-existing timelines on enwikipedia if they depend on letters to be specific sizes. Should be done with care in any case.
Comment 12 JeLuF 2011-02-05 21:16:49 UTC
FreeSerif looks better, but it's not perfect.
Look for the label of the red dot in the legend.
Comment 13 Bawolff (Brian Wolff) 2011-02-05 21:24:59 UTC
I believe that is caused by the new unicode 5 way of encoding a certain character as one code point (U+0D7E) instead of two code points separated by a ZWJ (U+D33 U+D4D U+200D). Presumably the older font doesn't support it. See bug 25623
Comment 14 JeLuF 2011-02-05 22:22:48 UTC
I'm tempted to have the font a per-timeline option, with FreeSans as default:

Index: Timeline.php
--- Timeline.php        (revision 72554)
+++ Timeline.php        (working copy)
@@ -48,8 +48,13 @@
        return true;

-function renderTimeline( $timelinesrc ){
+function renderTimeline( $timelinesrc, $attr ){
        global $wgUploadDirectory, $wgUploadPath, $IP, $wgTimelineSettings, $wgArticlePath, $wgTmpDirectory, $wgRenderHashAppend;
+       if ( isset( $attr[font] ) ) {
+               $wgTimelineSettings->fontFile = preg_replace( '/[^a-zA-Z0-9_-]/', '', $attr[font] ) . '.ttf';
+       }
        $hash = md5( $timelinesrc );
        if ($wgRenderHashAppend != "")
                $hash = md5( $hash . $wgRenderHashAppend );

<timeline font="FreeSerif">
Comment 15 JeLuF 2011-02-05 22:55:47 UTC
(In reply to comment #13)
> I believe that is caused by the new unicode 5 way of encoding a certain
> character as one code point (U+0D7E) instead of two code points separated by a
> ZWJ (U+D33 U+D4D U+200D). Presumably the older font doesn't support it. See bug
> 25623

The font I've used was from Ubuntu. Version 20060501cvs-12.

With FreeSerif from freefont-ttf-20100919 it works fine.

Unfortunately, FreeSans from that release still doesn't include Malayalam.
Comment 16 Bawolff (Brian Wolff) 2011-02-05 23:02:42 UTC
>I'm tempted to have the font a per-timeline option, with FreeSans as default

Hmm, that would make sense. I'm not sure why i didn't do that originally, or if there was a reason that i didn't do that originally (since the commit adding the font option was such a long time ago, and my memory doesn't really stretch that far back).
Comment 17 JeLuF 2011-02-06 13:34:49 UTC
I've tried to merge the Malayalam letters of FreeSerif into FreeSans, but the result has problems with U+0D7E.

I don't like the serif font for timelines, the letters are ugly to me at this small font size.
Comment 18 JeLuF 2011-02-06 13:58:04 UTC
Your change has been completed.
Please reopen this ticket if anything went wrong.
The following configuration settings have been changed:
Index: CommonSettings.php
--- CommonSettings.php	(revision 1573)
+++ CommonSettings.php	(working copy)
@@ -808,8 +808,8 @@
-if ( $wgDBname == "testwiki" ) {
-	$wgTimelineSettings->fontFile = "FreeSansWMF.ttf";
+if ( $wgDBname == 'testwiki' || $wgDBname == 'mlwiki' ) {
+	$wgTimelineSettings->fontFile = 'FreeSansWMF.ttf';
@@ -1127,7 +1127,7 @@
 	// Back-compat for Fedora boxes
 	$wgTimelineSettings->ploticusCommand = '/usr/local/bin/pl';
-$wgTimelineSettings->epochTimestamp = '20081209214953'; // fixed font setting
+$wgTimelineSettings->epochTimestamp = '20110206135500'; // fixed font setting
 $wgAllowRealName = false;
You can find the entire config file at
Comment 19 praveenp 2011-02-19 18:57:27 UTC
Created attachment 8174 [details]
No liguatures rendering
Comment 20 praveenp 2011-02-19 18:59:14 UTC

Please check this attachment. No ligature are rendering properly, each part displays independently. Is this anything related to ?
Comment 21 JeLuF 2011-02-20 06:58:47 UTC
Hi praveenp, can you please copy that sentence from the image here as text so that I can use it for some tests?
Comment 22 Junaid 2011-02-21 04:10:27 UTC
JeLuf, it is "ഉബുണ്ടു പുറത്തിറങ്ങുന്നതും പിന്തുണയും".
Comment 23 praveenp 2011-02-21 06:06:19 UTC
(In reply to comment #22)
> JeLuf, it is "ഉബുണ്ടു പുറത്തിറങ്ങുന്നതും പിന്തുണയും".

Taken from
Comment 24 Laurence 'GreenReaper' Parry 2011-02-21 06:09:10 UTC
For what it's worth, I always thought DejaVu Sans Condensed worked best for EasyTimeline. Compact yet readable. But perhaps it works less well for such languages.
Comment 25 Bawolff (Brian Wolff) 2011-10-25 14:01:18 UTC
btw, are we sure this is a font issue and not an easyTimeLine sucks issue? (Similar to how easy timeline doesn't support BIDI at all - bug 4030). CC'ing Amir on this bug since he's working on the bidi support in timeline, so he might be interested in this (in the case this really is a lack of program support issue not a font issue).
Comment 26 Amir E. Aharoni 2011-10-25 15:02:41 UTC
It is indeed impossible with the current software. I am rewriting it now to support modern graphics libraries that allow different fonts, ligatures, right-to-left etc.
Comment 27 Mark A. Hershberger 2012-03-21 16:39:26 UTC
dependency was in the wrong direction on Bug 8898
Comment 28 Siddhartha Ghai 2014-01-31 09:08:08 UTC
The font problem also affects devanagari. The problem is similar to Malayalam.
The viram character ् (U+094D) should result in two characters joining but the
text shows them separately.

For example, see the template [1]. The text

इस्लाम शाह सूरी (1545 - 1554)

near the bottom left (as an example) is rendered incorrectly. The labels
contain the word


which is also rendered incorrectly.

Please let me know if a screenshot/another bug is needed. Thanks.


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