Text difficult to read (subpixel rendering), need to add new fonts
OpenPublic

Description

The text rendered by EasyTimeline is often difficult to read. Check the link for an example.
It seems to be because the default font FreeSans.ttf uses subpixel rendering, which is altered when used with EasyTimeline.
Since Ploticus seems to support different fonts [1], EasyTimeline could be modified to allow changing the font. Or is there something that prevents it to be done ?

[1] http://ploticus.sourceforge.net/doc/fonts.html


Version: unspecified
Severity: major
URL: http://en.wikipedia.org/wiki/Enlargement_of_the_European_Union#Timeline

bzimport added a subscriber: Unknown Object (MLST).
bzimport set Reference to bz19139.
The_RedBurn created this task.Via LegacyJun 9 2009, 9:57 AM
Bawolff added a comment.Via ConduitFeb 5 2010, 7:41 AM

I added a configuration setting to control which font to use in r62018. Leaving this bug open as i assume its about changing the font, as opposed to adding a config setting to give the ability to change the font.

kaldari added a comment.Via ConduitAug 11 2012, 1:50 AM
  • Bug 35805 has been marked as a duplicate of this bug. ***
kaldari added a comment.Via ConduitAug 11 2012, 1:53 AM

Created attachment 10953
An example of the current rendering

Attached:

bzimport added a comment.Via ConduitAug 11 2012, 5:54 AM

erikzachte wrote:

I am no longer maintaining EasyTimeline, but here are some thoughts:

Perhaps anti-aliasing also plays a role, as embedded links in texts are written twice, which can deteriorate rendering. Ploticus does/did not know how to render links differently. As a workaround the whole line is written in black, then links are overwritten in blue.

Unrelated but added here for context: This approach worked reasonably well until someone changed the default font to a variable width font, to add unicode support. So now blue texts are even totally unreadable when not at the start of the text, due to misalignment.

Bawolff added a comment.Via ConduitAug 13 2012, 12:29 PM

Unrelated but added here for context: This approach worked reasonably well
until someone changed the default font to a variable width font, to add unicode
support.

How about using DjVu Sans mono. My understanding is that it is fixed width and reasonably supports unicode (and is pretty than your average fixed width font).

kaldari added a comment.Via ConduitAug 13 2012, 6:52 PM

Fixed width fonts are inherently hard to read. I would rather stick with a proportional font if possible.

There's actually no reason we have to use a free font for this extension since we're not distributing any fonts with the software. According to U.S. law (and most other countries as well) copyright is not applicable to typefaces (only to the fonts themselves). In other words, there is no associated intellectual property in the output of the font, only in the software of the font itself.

We should actually be using Arial Unicode MS:

Characters     Glyphs

Arial Unicode MS 38,917 50,377
DejaVu Sans 5,467 5,762
FreeSerif 7,203 8,995

Bawolff added a comment.Via ConduitAug 13 2012, 6:59 PM

But...What...About...The...Idealogical...Imperatives...And...Stuff...

kaldari added a comment.Via ConduitAug 13 2012, 7:18 PM

Heh, of course I would prefer a free font, but it seems to me that character support should trump ideological concerns. I'm sure others will beg to differ though ;)

matmarex added a comment.Via ConduitJan 16 2013, 10:32 PM

Bumping this. The font currently at use on Wikimedia wikis misses a lot of Unicode characters, including sub- and superscripted letters, which makes it impossible to create nice "references" within the timeline.

[As reported on pl.wikipedia's VPT: https://pl.wikipedia.org/w/index.php?title=Wikipedia:Kawiarenka/Kwestie_techniczne&oldid=34234197#problem_z_indeksem_g.C3.B3rnym]

Is this simply a matter of flipping a setting?

Bawolff added a comment.Via ConduitJan 17 2013, 1:31 AM

well that, putting the font on the server and the bikeshed of choosing which font to switch to. mlwiki already uses a different font than the rest of wikimedia if memory serves.

Note that changing the font can cause the spacing in existing diagrams to change. Additionally some of the problems with text quality probably have more to do with the rendering engine used than font chosen, so its not a magic bullet to change everything.

Aklapper added a comment.Via ConduitJan 17 2013, 11:06 AM

Refering to comment 9, problem is visible at https://upload.wikimedia.org/wikipedia/pl/timeline/5a461a2b8cc79fe0c543d43f72538ab2.png

Server configuration file at https://noc.wikimedia.org/conf/highlight.php?file=CommonSettings.php currently says
$wgTimelineSettings->fontFile = 'FreeSansWMF.ttf';

Bawolff added a comment.Via ConduitJan 17 2013, 12:37 PM

(In reply to comment #11)

Refering to comment 9, problem is visible at
https://upload.wikimedia.org/wikipedia/pl/timeline/
5a461a2b8cc79fe0c543d43f72538ab2.png

That looks like a using html whete html is not allowed problem. A new font will not fix that (although it may allow one to use premafe superscript glyphs if that cuttently doesnt work)

matmarex added a comment.Via ConduitJan 17 2013, 2:17 PM

(In reply to comment #12)

That looks like a using html whete html is not allowed problem. A new font
will
not fix that (although it may allow one to use premafe superscript glyphs if
that cuttently doesnt work)

Yes, I was unclear. That's what the person tried to use, then I suggested using Unicode sub- and superscripted glyphs, which turned out not to display in this font.

matmarex added a comment.Via ConduitJan 17 2013, 2:25 PM

The real issue can be seen here: https://pl.wikipedia.org/w/index.php?title=Wikipedysta:Matma_Rex/brudnopis&oldid=34244322

All glyphs display for me in both monospace and sans-serif font (I happen to use DejaVu Sans Mon and Trebuchet MS), only a few display on the timeline.

The_RedBurn added a comment.Via ConduitSep 12 2013, 3:04 PM

(In reply to comment #10)

well that, putting the font on the server and the bikeshed of choosing which
font to switch to. mlwiki already uses a different font than the rest of
wikimedia if memory serves.

Note that changing the font can cause the spacing in existing diagrams to
change. Additionally some of the problems with text quality probably have
more
to do with the rendering engine used than font chosen, so its not a magic
bullet to change everything.

Is there a way to get a list of pages using EasyTimeline?

If it's too risky to try a global change of font, a temporary feature could be added to specify an alternate font when using EasyTimeline (in addition to the font size).
If that alternate font works everywhere, it could then be set by default and both the current font and that temporary feature be removed.

Add Comment