Last modified: 2006-09-10 11:13:49 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 7252 - Patch to enable dvipng support in math rendering
Patch to enable dvipng support in math rendering
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-07 07:39 UTC by Jan-Åke Larsson
Modified: 2006-09-10 11:13 UTC (History)
0 users

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


Attachments
Patch to enable dvipng (1.49 KB, patch)
2006-09-07 07:41 UTC, Jan-Åke Larsson
Details

Description Jan-Åke Larsson 2006-09-07 07:39:53 UTC
I have written a small patch to enable dvipng in the math rendering. I have
tried to make the rendering behave as before if dvipng fails for some reason, or
if it is not present on the system.
Comment 1 Jan-Åke Larsson 2006-09-07 07:41:53 UTC
Created attachment 2322 [details]
Patch to enable dvipng
Comment 2 Jan-Åke Larsson 2006-09-07 07:43:55 UTC
My tests indicate a speedup on the order of a factor 3.

I don't have a MediaWiki server to try it on, nor any real knowledge of
ocaml, so I wrote a small python snippet that re-rendered the same image
again and again, using the os.system() call.

Based on other experience, I expected something like two orders of
magnitude more, but here, the repetitive call to dvipng on a one-page
DVI makes for an overhead in startup time. Example:

100 one-page DVIs, one image per DVI, dvips->convert: 120 s
100 one-page DVIs, one image per DVI, dvipng:         39 s, a factor 3

(my machine, YMMV)


If one is willing to put in some more work instead of my simpleminded
patch there is more to gain, say if one were to collect math into larger
DVI files:

100-page DVI, one image per page,     dvipng:        0.5 s, a factor 240

This collection of images is perhaps not desirable in MediaWiki. But it
is also entirely possible to run dvipng in deamon mode, telling it which
DVI to render and the desired output file...

100 one-page DVIs, one image per DVI, deamon dvipng:  1 s, a factor 120

That would of course increase with the number of DVIs you render. The
startup/shutdown of the program is 0.4 s, so each DVI rendered is
0.6/100=0.006 s. Compare that to the 1.2 s via the dvips->convert route.
If startup is done _once_ and all images rendered with an already
running dvipng, the factor is 200. This would involve having a dvipng
process running indefinitely on the server, but makes for interesting
prospects, no?

Email me if there are any questions. I don't know much about ocaml but I do know
the innards of dvipng.
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-09-07 21:12:19 UTC
By default, any modifications or comments to this bug will e-mail you (you can
change that in your preferences).
Comment 4 Domas Mituzas 2006-09-08 09:06:32 UTC
Jan-Åke,

I see you're the author of dvipng itself - could have told about that. :)

Anyway, right now dvipng is on our FC4 boxes, but not on FC3, which still are considerable majority. I tried backporting whole tetex package, but it is too big for manual fixes. 

What is the status of dvipng on sourceforge? How is it related to tetex?
Comment 5 Domas Mituzas 2006-09-08 09:26:13 UTC
OK, I see that tetex package has 1.5 release of dvipng. I'll probably roll our own RPM for FC3 boxes. 

Is it worth to have 1.8 release for FC4 too?
Comment 6 Jan-Åke Larsson 2006-09-08 09:38:31 UTC
The devel takes place on savannah.nongnu.org, but you can download from
SourceForge too. dvipng is included in tetex-3 (and TeXlive and MIKTeX, but I
don't know what version you'll need, any recent would do). There are dvipng rpms
floating around, but only old ones.

You can download, build and install the source distribution in any UNIX  with a
proper build environment. Installing dvipng should be simple: merely
./configure, make, and make install. Otherwise, see
http://www.nongnu.org/dvipng/dvipng_2.html#SEC2

It would probably not be difficult to write a .spec file, but I haven't got a
RedHat machine at the moment to try it on. 

You absolutely want 1.8 on both machines, and you want it to link to a recent
FreeType. You see, the output quality is improved if you do that, otherwise
horizontal lines (as in "=") may be spread over two pixel rows, resulting in
blurry output.
Comment 7 Domas Mituzas 2006-09-08 10:04:59 UTC
I built http://dammit.lt/tech/packages/

Probably I'll want versioned binaries. *shrug*, this package should get conflicts on our FC4 boxes...
Comment 8 Jan-Åke Larsson 2006-09-08 10:31:08 UTC
That was fast. There'll probably be conflicts, unless you manage to put the
binary in a path component that precedes the tetex path.

If/when you have questions about how to use daemon mode, just ask.
Comment 9 Domas Mituzas 2006-09-10 11:13:49 UTC
dvipng 1.8 deployed on site, patch above committed into trunk, wikimedia RPMs for both dvipng and texvc can be found at http://dammit.lt/tech/packages/

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


Navigation
Links