I have taken a look at render.ml and have written a patch that will enable the use of the PNG-rendering program dvipng. This would reduce load on the server, and also enable full-alpha transparency (but I havent included that yet, IE has problems with full-alpha PNGs).
There is already a patch somewhere, but in this attempt I have tried to make sure that the old dvips->convert renderer is used in the case dvipng fails (or indeed, is not present on the system). Unfortunately I do not have a server to test it on. Does anyone want to try it?
The patch is small, so I suppose there is no real harm in including it here.
/Jan-Åke
Index: render.ml =================================================================== --- render.ml (revision 16007) +++ render.ml (working copy) @@ -2,6 +2,10 @@ let cmd_latex tmpprefix = "latex " ^ tmpprefix ^ ".tex >/dev/null" (* Putting -transparent white in converts arguments will sort-of give you transperancy *) let cmd_convert tmpprefix finalpath = "convert -quality 100 -density 120 " ^ tmpprefix ^ ".ps " ^ finalpath ^ " >/dev/null 2>/dev/null" +(* Putting -bg Transparent in dvipng's arguments will give full-alpha transparency *) +(* Note that IE have problems with such PNGs and need an additional javascript snippet *) +(* Putting -bg transparent in dvipng's arguments will give binary transparency *) +let cmd_dvipng tmpprefix finalpath = "dvipng -gamma 1.5 -D 120 -T tight --strict " ^ tmpprefix ^ ".dvi -o " ^ finalpath ^ " >/dev/null 2>/dev/null"
exception ExternalCommandFailure of string
@@ -25,9 +29,11 @@ close_out f; if Util.run_in_other_directory tmppath (cmd_latex tmpprefix0) != 0 then (unlink_all (); raise (ExternalCommandFailure "latex")) - else if (Sys.command (cmd_dvips tmpprefix) != 0) + else if (Sys.command (cmd_dvipng tmpprefix (finalpath^"/"^md5^".png")) != 0) + then (if (Sys.command (cmd_dvips tmpprefix) != 0) then (unlink_all (); raise (ExternalCommandFailure "dvips")) else if (Sys.command (cmd_convert tmpprefix (finalpath^"/"^md5^".png")) != 0) then (unlink_all (); raise (ExternalCommandFailure "convert")) + else unlink_all ()) else unlink_all () end
Jan-Åke Larsson wrote:
Does anyone want to try it?
Apparently not. There are two possibilities: a) render.ml isn't used anymore now that WikiTeX exists b) nobody cares enough or all are immersed in the wysisyg debate c) There is a different mailing list that discusses texvc
In any case, can someone please enlighten me as to whether the caml syntax I used is correct, i.e., "then (if (foo) then bar else baz) else fooo". The dvipng call is correct, I know.
/JÅ
Jan-Åke,
a) render.ml isn't used anymore now that WikiTeX exists
Did you do any benchmarks? Because that's what I thought we'd do before rolling it live on wikipedia ;-) How much faster is the dvipng approach?
BR,
Domas Mituzas wrote:
Did you do any benchmarks? Because that's what I thought we'd do before rolling it live on wikipedia ;-) How much faster is the dvipng approach?
My tests indicate 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?
/JÅ
Jan-Åke Larsson wrote:
Jan-Åke Larsson wrote:
Domas Mituzas wrote:
How much faster is the dvipng approach?
My tests indicate a factor 3.
What, no cheers? :-) Are there comments, opinions?
Apparently there is no interest in this. Pity.
I'll stay subscribed one week from now (longer if there is any response at all).
/JÅ
Jan,
Apparently there is no interest in this. Pity.
I'll stay subscribed one week from now (longer if there is any response at all).
Sorry - your stuff is great, it is just that... volunteer priorities are pretty mixed, and they tend to forget. :-) We definitely want this code to replace our current math rendering - it just needs attention and dev time (I personally would have to install all ocaml environments to test ;-)
BR,
Domas Mituzas wrote:
Apparently there is no interest in this. Pity.
Sorry - your stuff is great, it is just that... volunteer priorities are pretty mixed, and they tend to forget. :-) We definitely want this code to replace our current math rendering - it just needs attention and dev time (I personally would have to install all ocaml environments to test ;-)
Ah, good. I'll stay subscribed, then. (I'd do it myself, but I don't have an environment ready, and precious little time too.)
/JÅ
On a side note, I read in another thread that:
The procedure is to file a feature request (bug) at http://bugs.wikimedia.org/, then attach this as a patch. That provides a centralized place to discuss, note updates, get people to vote for it, etc.
Should perhaps I follow this advice, and watch the created bug instead of lurking on this list?
/Jan-Åke
On 9/6/06, Jan-Åke Larsson jalar@mai.liu.se wrote:
On a side note, I read in another thread that:
The procedure is to file a feature request (bug) at http://bugs.wikimedia.org/, then attach this as a patch. That provides a centralized place to discuss, note updates, get people to vote for it, etc.
Should perhaps I follow this advice, and watch the created bug instead of lurking on this list?
Probably a good idea. Certainly lower-upkeep on your part, you won't have to pick through all the list messages.
Simetrical wrote:
Should perhaps I follow this advice, and watch the created bug instead of lurking on this list?
Probably a good idea. Certainly lower-upkeep on your part, you won't have to pick through all the list messages.
OK, thanks <signing off> /JÅ
On 9/7/06, Jan-Åke Larsson jalar@mai.liu.se wrote:
OK, thanks <signing off> /JÅ
For anyone who wishes to follow this, the bug is http://bugzilla.wikimedia.org/show_bug.cgi?id=7252.
wikitech-l@lists.wikimedia.org