Timwi <timwi(a)gmx.net> writes:
David Kastrup wrote:
Brion Vibber <brion(a)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.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum