Timwi timwi@gmx.net writes:
David Kastrup wrote:
Brion Vibber brion@pobox.com writes:
Saying it's easy is nice, providing code to do it is better. ;)
What do you mean, "to do it"?
He means, send us a patch to the MediaWiki software that implements your suggestion.
Since I don't even know what language your converters are written in, this would be hard to do.
With preview.sty, the output is written into a single line,
Either I'm dumb, or you have never mentioned how to get it (what anyway? dvips or what?) to output this "single line".
Pass the "lyx" option to the preview package. I won't go looking for Message Ids.
It should be a one-liner in most scripting languages.
Often the difficult thing is not to write the one line, but to figure out where in the code to put it.
Right. This is the reason that I was telling the people that supposedly know the code about this possibility.
Additionally, you're forgetting that the LaTeX is (obviously) not rendered and re-rendered and re-re-rendered for every single pageview.
I am not forgetting anything. Obviously, the rendered final HTML (which includes the ascender information, as well as the image dimensions, as well as math rendered into HTML instead of PNG) has to get cached somewhere already now. Whether the images can be cached depends on whether you want to go for the image-size-fits-browser-font-size hacks of Jan-Åke, or just render at a fixed size. Since dvipng is rather light on resources and can even be run continuously, it would be quite feasible to cache the .dvi files (which are size independent) and rerender the png dynamically.
But of course you need not implement everything at once. Just replacing your current image generating process (which already _is_ there) with a dvipng-based process would be a start.
The images are cached. Hence you would also need to come up with a way to cache these extra values, and then tell the parser to output them in the right place.
Does that mean that the Wiki pages are created dynamically each time and only the images get cached? The usual HTML specifications _strongly_ recommend that the image dimensions are specified already in the HTML so that the page layout engine needs not relayout the page every time an image download completes. So in case you are _not_ already caching the image dimensions, it might be an idea to do so.
Programming that in PHP into the MediaWiki software is what Brion meant by "the code to do it".
Shrug. As you please. I am just telling you that software is here that would quite benefit the appearance and efficiency of your software. I am willing to help doing what it takes to get you the most of it from our project. Jan-Åke, the author of dvipng, already offered you the respective code to generate the HTML dynamically in perl.
I can't say anything about him, of course, but I don't have the resources to do your work. I'll help with what it takes on the side of preview.sty and other tools from our project to work for your application (and they should actually work rather out of the box), but that's about it. It would be unfair to the users and developers of my own projects if I invested the time needed to get acquainted with yours, because the benefits are considered so small that nobody in the project itself would want to invest any work on reasonably good-looking math.