Last modified: 2006-09-10 11:13:49 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.
Created attachment 2322 [details] Patch to enable dvipng
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.
By default, any modifications or comments to this bug will e-mail you (you can change that in your preferences).
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?
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?
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.
I built http://dammit.lt/tech/packages/ Probably I'll want versioned binaries. *shrug*, this package should get conflicts on our FC4 boxes...
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.
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/
