Page MenuHomePhabricator

Allow using custom fonts with EasyTimeline
Closed, ResolvedPublic

Description

Instead of creating Malayalam Characters EasyTimeLine renders squares.


Version: unspecified
Severity: major
URL: http://ml.wikipedia.org/wiki/Template:Ubuntu_Calendar
See Also:
T22825: Change default font for EasyTimeline on zh projects to something that actually has glyphs for Chinese characters

Details

Reference
bz21497

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:54 PM
bzimport added projects: EasyTimeline, I18n.
bzimport set Reference to bz21497.
bzimport added a subscriber: Unknown Object (MLST).

Created attachment 6776
Problem Screenshot

attachment EasyTimeLine.png ignored as obsolete

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 EasyTimeline.pl , So i'd imagine it wouldn't be too difficult to allow alternate fonts to be selected by the user.

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.

If lack of font is the only problem then I think I can arrange atleast one ;-)

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.

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: http://upload.wikimedia.org/wikipedia/ml/timeline/3e53b63091049c25cc1bbbbd366bb4a7.png ) change the extension to svg ( so http://upload.wikimedia.org/wikipedia/ml/timeline/3e53b63091049c25cc1bbbbd366bb4a7.svg ). 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.

Created attachment 7015
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 ;-)

Attached:

Screenshot-Mozilla_Firefox-1.png (813×1 px, 135 KB)

junu.pv+public wrote:

Adding an option to produce SVG instead of PNG and setting encoding to utf-8 should solve the problem. won't it?

erikzachte wrote:

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 http://infodisiac.com/Wikimedia/Perl/EasyTimeline_1.15.zip 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.

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 .

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.

jeluf wrote:

FreeSerif looks better, but it's not perfect.
http://test.wikipedia.org/wiki/User:JeLuF/21497
Look for the label of the red dot in the legend.

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

jeluf wrote:

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">

.....

</timeline>

jeluf wrote:

(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.

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).

jeluf wrote:

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.

jeluf wrote:

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 @@
include($IP.'/extensions/timeline/Timeline.php');
include($IP.'/extensions/wikihiero/wikihiero.php');

-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
putenv("GDFONTPATH=/usr/local/apache/common/fonts");

$wgAllowRealName = false;

You can find the entire config file at
http://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php

Created attachment 8174
No liguatures rendering

Attached:

Easytimeline-error.jpg (177×559 px, 19 KB)

https://bugzilla.wikimedia.org/attachment.cgi?id=8174

Please check this attachment. No ligature are rendering properly, each part displays independently. Is this anything related to https://bugzilla.wikimedia.org/show_bug.cgi?id=25140 ?

jeluf wrote:

Hi praveenp, can you please copy that sentence from the image here as text so that I can use it for some tests?

junu.pv+public wrote:

JeLuf, it is "ഉബുണ്ടു പുറത്തിറങ്ങുന്നതും പിന്തുണയും".

(In reply to comment #22)

JeLuf, it is "ഉബുണ്ടു പുറത്തിറങ്ങുന്നതും പിന്തുണയും".

Taken from http://ml.wikipedia.org/wiki/Template:Ubuntu_Calendar

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.

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).

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.

dependency was in the wrong direction on Bug 8898

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.

[1]: https://hi.wikipedia.org/s/734m

hashar set Security to None.

Looks like for Devanagari we would need to change the font similar to what is being looked at for Chinese (T22825).

Maybe the home made FreeSansWMF.ttf can be replaced by unifont.ttf

Mahir256 subscribed.

I am rewriting it now to support modern graphics libraries that allow different fonts, ligatures, right-to-left etc.

Any updates, @Amire80, over six years on?

Sorry, no. I had tried, and the most that I managed to do is to make it work with SVG, although it wasn't perfect.

EasyTimeline should be deprecated because its underlying graphics library is completely unmaintained upstream, and there's nobody in the Wikimedia community who can maintain it. Instead of rewriting EasyTimeline, it should be replaced with the Graph extension, or something like that.

The biggest problem, of course, is that the current timelines on wikis will have to be rewritten to support the new format, but its worth the effort.

Cannot reproduce anymore:

Screenshot from 2022-02-15 21-40-49.png (764×1 px, 131 KB)

If there is still an issue, please open a new ticket - thanks!