Last modified: 2013-09-12 15:04:58 UTC
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
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.
*** Bug 35805 has been marked as a duplicate of this bug. ***
Created attachment 10953 [details] An example of the current rendering
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.
>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).
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
But...What...About...The...Idealogical...Imperatives...And...Stuff...
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 ;)
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?
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.
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';
(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)
(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.
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.
(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.
